[core] Make time selection more intuitive #181
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sometimes the shown time from the Options component in a toolbar was not very meaningful. Especially when a user opened a shared URL, were the user select a last x minutes interval, we showed this text, instead of the correct time range, also when the last x minutes referred to an very old time. Now we are always showing the formatted timestamp, so that this problem can not occure anymore. It is still possible to refresh a time range, so that the current time is used as end time with the formaly selected diff between the start and end time. If you are using the options component in one of your plugins, you have to adjust the passed in values, so that your plugin works with the next release of kobs. NOTE: Maybe we can also remove some duplicated code for the toolbar and the state handling via the URL in the future.
ricoberger
added a commit
that referenced
this pull request
Dec 9, 2021
This commit changes the options handling again. In #181 we removed the time parameter and since then we always showed the absolute time in the options button. It turned out that this was very unintuitive for users, so that we re-add the "time" property and show the relative time (e.g. when a user selects "Last 15 Minutes"). We replaced the Options component with a Toolbar component, so that we only display one button to trigger the search. Before this we displayed a refresh button and a search button, which confused users. They didn't exactly know when to use which button. Now with only one button displayed we use a similar approach like Grafana, Kibana, etc. that the time is always refreshed when the time is relative and the user clicks on the search button. We also use the current url only to get the initial options for a component. When the user changes the options, we adjust the url and directly adjust the options state, instead of using the adjust url to set the new options.
3 tasks
ricoberger
added a commit
that referenced
this pull request
Dec 9, 2021
This commit changes the options handling again. In #181 we removed the time parameter and since then we always showed the absolute time in the options button. It turned out that this was very unintuitive for users, so that we re-add the "time" property and show the relative time (e.g. when a user selects "Last 15 Minutes"). We replaced the Options component with a Toolbar component, so that we only display one button to trigger the search. Before this we displayed a refresh button and a search button, which confused users. They didn't exactly know when to use which button. Now with only one button displayed we use a similar approach like Grafana, Kibana, etc. that the time is always refreshed when the time is relative and the user clicks on the search button. We also use the current url only to get the initial options for a component. When the user changes the options, we adjust the url and directly adjust the options state, instead of using the adjust url to set the new options.
ricoberger
added a commit
that referenced
this pull request
Dec 9, 2021
This commit changes the options handling again. In #181 we removed the time parameter and since then we always showed the absolute time in the options button. It turned out that this was very unintuitive for users, so that we re-add the "time" property and show the relative time (e.g. when a user selects "Last 15 Minutes"). We replaced the Options component with a Toolbar component, so that we only display one button to trigger the search. Before this we displayed a refresh button and a search button, which confused users. They didn't exactly know when to use which button. Now with only one button displayed we use a similar approach like Grafana, Kibana, etc. that the time is always refreshed when the time is relative and the user clicks on the search button. We also use the current url only to get the initial options for a component. When the user changes the options, we adjust the url and directly adjust the options state, instead of using the adjust url to set the new options.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Sometimes the shown time from the Options component in a toolbar was not
very meaningful. Especially when a user opened a shared URL, were the
user select a last x minutes interval, we showed this text, instead of
the correct time range, also when the last x minutes referred to an very
old time.
Now we are always showing the formatted timestamp, so that this problem
can not occure anymore. It is still possible to refresh a time range, so
that the current time is used as end time with the formaly selected diff
between the start and end time.
If you are using the options component in one of your plugins, you have
to adjust the passed in values, so that your plugin works with the next
release of kobs.
NOTE: Maybe we can also remove some duplicated code for the toolbar and
the state handling via the URL in the future.
Fixes #178.