How do you design your UX to support a bi-temporal immutable DBMS? If you have entity types that should be shown together with other entity-types (such as Order and Product), do you always show the latest version of associated entities or the versions that were valid at the time the main entity was created? We’re currently always showing the latest version of entities, i.e. we might as well use a traditional mutable DBMS - there would be no practical difference to our users.
If we changed our UX to pay attention to the valid times of associated entities, we would adopt the strictness of blockchain dAPPs which wouldn’t be very user-friendly.
For example, there’s an order and it has a product. After that order was created, someone might create a new version of that product to:
- correct a spelling mistake in the description (i.e. the valid time should be the same as the original product version’s valid time)
- change the price (i.e. the valid time should be later than the latest order for that product)
- instead of deleting a product (“apple”) that’s no longer available and creating a new product (“orange”) that is now available, our “efficient” admin-user decides to just change all the properties of the apple to become the orange (oh god!)
How do you design your GUI so that 1) is clearly distinguished from 2)? Would users understand it if we exposed the valid time in the edit forms? And how might a GUI discourage 3), and also discourage trying to do 1) and 2) within the same transaction?
And what if the spelling mistake was discovered after the price change? Now we’re getting into branching territory, something I’d definitely don’t want in the DB or UX.
If anybody has come across any good articles or examples, or has any experience to share on this topic, I’d appreciate it.
Hey @xpekeler - this is an excellent conversation opener 
How do you design your GUI so that 1) is clearly distinguished from 2)?
And how might a GUI […] discourage trying to do 1) and 2) within the same transaction?
I think a somewhat unsatisfying answer to these specific questions is to simply model the price and the description using separate ‘child’ entities. I think that may also address the “what if the spelling mistake was discovered after the price change?” scenario. However modelling is hard, and performance will suffer if everything involves joining across tiny entities ~needlessly, so this isn’t always the best compromise.
It is tempting to advise applying some rigorous methodology to help with modelling, like Object–role modeling - Wikipedia, but I don’t have enough direct experience with these kinds of methods in practice to recommend anything in particular.
Would users understand it if we exposed the valid time in the edit forms?
I have found that non-technical users grok valid-time quite readily when explained with meaningful examples, although it may well depend on the sophistication of your users and domain/industry.
And how might a GUI discourage 3)
Perhaps some lightweight diffing threshold / feedback (e.g. “80% of fields/values are changed”) could prompt a warning/confirmation, i.e. “You are attempting to heavily edit an existing record - please be aware that this system will perform better when creating new records rather than attempting to re-purpose old records with new data. Do you wish to proceed with the edit?”
model the price and the description using separate ‘child’ entities
Thanks. In our case, a product has 15 attributes and each of them could have a false entry, i.e. our product would have to be composed of 15 child-entities. And it’s similar for our other entities so that approach feels wrong 
I have found that non-technical users grok valid-time quite readily
Interesting! Would you be at liberty to share a screenshot of a GUI that exposes valid-time?
And how might a GUI discourage 3)
I figured that this is a problem mainstream mutable DB systems would often have, too, so I asked over here interaction design - Prevent users from changing entity data fundamentally - User Experience Stack Exchange
1 Like
Would you be at liberty to share a screenshot of a GUI that exposes valid-time?
I haven’t built one with xt personally, but we have heard of quite a few folks doing this (whether using xt or not). I think the fundamental property here is that mostly xt behaves as if it were just a regular boring mutable database. XT is useful for tracking these things almost as you might do so manually (as part of your domain) but save you from all the obnoxious queries in the default cases where you largely just want entities as-of-now.
I’ll keep an eye out for a strong exemplary valid-time UI, but on the whole they’ll look like any other UI which uses “effectivities” or equivalent temporal patterns, if you’ve seen something in that vein.