Page History
DACI Decision
| Page properties | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Tips and info
| Tip | ||
|---|---|---|
| ||
| Info | ||
|---|---|---|
| ||
Contributors: I am seeking the right people to get involved in the decision. Add your comments to this page, let's get the conversation started. Please add:
|
| Info | |||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||||||||||||||||
|
Background
The currently proposed way of handlig time in EdgeOne is based on Sapient. Many users find it very confusing and also the developers have problems to implement requirements properly.Â
Current state
- The UI is designed to present one Board with multiple Boardlets. Boardlets are split into two groups:
- Boardlets for data entry. (e.g. Forms)
- Boardlets for data aggregation and analysis. (e.g. Tables, Charts.)
- Each Boardlet (especially type 2) can be set to a timespan. The time span can be defined in two ways:
- Absolute time span. (e.g. 1.1.2019 - 31.12.2019 )Â -Â The time is fixed here.
- Relative time span. (e.g. Last Shift, Last Week, Current Year, Previous Month, etc... )
- A Boardlet is able to inherit its time setting from the Board (or other parent), BUT it doen't have to. It can ignore the setting from 'above' and override it.
- Moreover a user is able to change the time span of the board. (global time).
All this leads to confusing states in the user interface and many complex questions:
- One has to explore the configuration of the Board and all Boardlets
- How do we store the changes made by the end user? For that reason Sapient introduces UserViews where such settings are stored. But that causes immense complexity (e.g. do we update such settings, when some other user changes the config on the Board)
- There are too many options on different levels to deal with time settings.Â
Data for decision support
The proposal is to remove complexity by introducing rules which limit the options and thus simplifying the whole mechanism.
- The global time setting will only allow to set one point in time (e.g. Now, Yesterday 12:00 or 1/1/2019 0:00 ) this can be labled with aliases of course
- Boarlets do have a relative time setting relative to the global time . (e.g. Last Week - would mean: GlobalTime minus 7 days until GlobalTime")
Such rules will have the effect that one can "time travel" with the whole board by changing the global time, therefore I'll suggest using this as the name for the feature.
| View file | ||||
|---|---|---|---|---|
|
Of course it should be possible to easily switch the local time temporarly inside the analysis boardlets (eg. switching month back and forth with arrows  " (<) November (>) " )
Comments
- Erwin Vervondel
I like the prosopal more than the original suggestion.
- the end-user (operator) should not be bothered with the choice of what boardlets to update when changing a global time
- When a boardlet is global 'time-aware' it should follow the global time
- but: some dashboards might be set up to be able to compare 2 time ranges... e.g. to compare 2 shifts. But then this will be more on a 'predefined' dashboard with their own time selectors... >> this would be a 'dashboard' designer decision then Matthias Fiebig
Hello colleagues, first of all my own opinion: I think this relative time reference is very helpful for many use cases. At the same time, however, there are applications where you want to see concrete time periods. For example, the comparison of several concrete months regardless of when the comparison is carried out. Therefore, "relative time reference" is an option for boardlets and this should also be easily recognizable. Alternatively, you can reverse this and use the concrete definition of time as an option.We will discuss this within our team.having a fixed point in time as reference and make all other information relativ makes sense to me.
Following thoughts arise:
- what is the impact on perceived performance? If the reference point changes all boards need to be reloaded. Does this make sense e.g. in a scenario when a user only is interested in the time travel on one specific board?
- how do we support useres that want to focus in on a specific information domain. e.g trying to understand the development of OEE on a specific node in the past 4 shifts and relate this to alarms? Does the reference and time travel metaphor also work for this one? Or would we offer a different set of capabilities for this scenario?since time selection is a highly criticized element in Legato Sapient, we could also use a new control logic here. It would be worth considering whether we can do this, given that many will continue to work with Sapient for some time. So, what about VWN? Can we involve them? I heard at noon today that they were expecting optimizations regarding Gui in Sapient. We can then use the feedback for Germanedge as well.
Options considered
Â
| Option 1: Do nothing | Option 2: | Option 3: | |
|---|---|---|---|
Description | Status quo. As described above. | Introducing the Time Travel Feature | Only boardlet filter with possibility to apply the filter to the whole board. |
Rollout plan | |||
| Pros and cons |
|
|
|
Risks |
|
| |
Estimated cost and effort |
FAQ
Q1.
A1.
References
| Expand | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Follow-up action items
- Â
Learn more: https://www.atlassian.com/team-playbook/plays/daci
Copyright © 2016 Atlassian
This work is licensed under a Creative Commons Attribution-Non Commercial-Share Alike 4.0 International License.
