[
https://issues.apache.org/jira/browse/METRON-2190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Meller updated METRON-2190:
---------------------------------
Description:
h2. Loading indicator and blocking loading state
The loading indicator will be applied for both manual and automatic alert entry
querying but in a different way (manual blocking, auto nonblocking).
*Loading state of a manual query* better to block the UI with a modal load
indicator. Changing grouping, filtering, querying, time range change, turning
automatic querying on/off, changing show/hide toggles or sorting could all
trigger another search request. We would like to prevent this (having multiple
operations) so it is better to block these operations while UI waiting for a
response.
*Loading triggered by automatic querying* indicated with a smaller spinner
close to the Play icon and it's blocking no interaction with other parts of the
UI. The automatic query should be canceled if the user triggers a manual query
or when the next automatic query triggered by the timer (as a later improvement
we can warn the user about getting no answer within the refresh period).
With this fix, we can prevent UI fireing and listen to multiple query responses
at the same time.
UPDATE: The actual implementation contains no loading indication for non
blocking loading, bc we haven't find any good UX for that.
h2. A) Issue: Lack of loading indicator (spinner)
There is no indicator such as a "spinner" that a query is pending/executing, so
if the screen does not change, you have no idea (or if you were not watching as
it changed). This is a problem when queries do not return immediately,
considering the issue where there are multiple pending queries.
h2. B) Issue: allowing Multiple pending Query Requests
For Solr queries that are not sub-second, as they are submitted and responses
are still pending, requests queue up and results start updating the UI in order
as they come in. If queries are really slow, this can become very confusing as
3-4 changes may happen in the UI.
was:
h2. Loading indicator and blocking loading state
The loading indicator will be applied for both manual and automatic alert entry
querying but in a different way (manual blocking, auto nonblocking).
*Loading state of a manual query* better to block the UI with a modal load
indicator. Changing grouping, filtering, querying, time range change, turning
automatic querying on/off, changing show/hide toggles or sorting could all
trigger another search request. We would like to prevent this (having multiple
operations) so it is better to block these operations while UI waiting for a
response.
*Loading triggered by automatic querying* indicated with a smaller spinner
close to the Play icon and it's blocking no interaction with other parts of the
UI. The automatic query should be canceled if the user triggers a manual query
or when the next automatic query triggered by the timer (as a later improvement
we can warn the user about getting no answer within the refresh period).
With this fix, we can prevent UI fireing and listen to multiple query responses
at the same time.
h2. A) Issue: Lack of loading indicator (spinner)
There is no indicator such as a "spinner" that a query is pending/executing, so
if the screen does not change, you have no idea (or if you were not watching as
it changed). This is a problem when queries do not return immediately,
considering the issue where there are multiple pending queries.
h2. B) Issue: allowing Multiple pending Query Requests
For Solr queries that are not sub-second, as they are submitted and responses
are still pending, requests queue up and results start updating the UI in order
as they come in. If queries are really slow, this can become very confusing as
3-4 changes may happen in the UI.
> [UI] Alerts UI: Indicating loading and preventing parallel requests
> -------------------------------------------------------------------
>
> Key: METRON-2190
> URL: https://issues.apache.org/jira/browse/METRON-2190
> Project: Metron
> Issue Type: Bug
> Reporter: Tibor Meller
> Assignee: Tibor Meller
> Priority: Major
>
> h2. Loading indicator and blocking loading state
> The loading indicator will be applied for both manual and automatic alert
> entry querying but in a different way (manual blocking, auto nonblocking).
> *Loading state of a manual query* better to block the UI with a modal load
> indicator. Changing grouping, filtering, querying, time range change, turning
> automatic querying on/off, changing show/hide toggles or sorting could all
> trigger another search request. We would like to prevent this (having
> multiple operations) so it is better to block these operations while UI
> waiting for a response.
> *Loading triggered by automatic querying* indicated with a smaller spinner
> close to the Play icon and it's blocking no interaction with other parts of
> the UI. The automatic query should be canceled if the user triggers a manual
> query or when the next automatic query triggered by the timer (as a later
> improvement we can warn the user about getting no answer within the refresh
> period).
> With this fix, we can prevent UI fireing and listen to multiple query
> responses at the same time.
>
> UPDATE: The actual implementation contains no loading indication for non
> blocking loading, bc we haven't find any good UX for that.
> h2. A) Issue: Lack of loading indicator (spinner)
> There is no indicator such as a "spinner" that a query is pending/executing,
> so if the screen does not change, you have no idea (or if you were not
> watching as it changed). This is a problem when queries do not return
> immediately, considering the issue where there are multiple pending queries.
> h2. B) Issue: allowing Multiple pending Query Requests
> For Solr queries that are not sub-second, as they are submitted and responses
> are still pending, requests queue up and results start updating the UI in
> order as they come in. If queries are really slow, this can become very
> confusing as 3-4 changes may happen in the UI.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
