Handling Time in EdgeOne

DACI Decision

Status	IN PROGRESS
Impact	Global way of handling time in all software based on EdgeOne
Driver	Michael Matejko
Approver	Christian von Stengel
Contributors	Gretz Gregor Sascha Ziegler Christoph Schiffer Erwin Vervondel Olaf Lummer Ron Oemus Christian Ehrenschwendtner[X]Frank Fuchs[X] Matthias Fiebig Arndt Dallmann Christian von Stengel Florian Hofmann[X]
Informed	ALL
Due date	30 Nov 2019
Outcome

Tips and info

Recommendations

Contributors

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:

The people directly impacted by this so we can include them.
Any references to previous work and investigations that we can leverage.
Any constraints and challenges we need to consider to make this decision and following action plan.

Impact rating

Here's an example you can use as a guide.

Decision characteristics
The decision will have a material impact on the customer experience OR will significantly impact the roadmap OR will adversely disrupt an internal business process.	HIGH
The decision will involve a less than material change to customer experience OR will impact the roadmap OR will impact an existing internal business process	MEDIUM
All other decisions	LOW

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:
1. Boardlets for data entry. (e.g. Forms)
2. 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:
1. Absolute time span. (e.g. 1.1.2019 - 31.12.2019 ) - The time is fixed here.
2. 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.

2019-10-23 15-56-19.mp4

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 (>) " )

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	Highly customizable UI It is possible to change the time span for Boardlets, even if it doesn't make any sense. Eg. Setting a Shift on a Calendar displaying the whole month.	Comprehensive for end users Fewer problems with implementation Possibility to change different filters with one change Restricted way of dealing with time settings. Reload of all boardlets while changing global time	less complexity for user less complexity for developers no "hidden overwritten" time filters Change multiple relative filters takes more time than in option 2
Risks	Complex software Vulnerable for mistakes made by developers	Probably we aren't able to implement all use cases and requirements from our customers
Estimated cost and effort