Steer collapsible forms via layout.

While I can imagine that data in certain sections becomes relevant or less relevant, I’m not convinced that Layout logic should be used.

Layout logic is ‘stateless’.

This means that the Layout logic doesn’t ‘update’ the current state of fields on the form based on the current state, but instead the desired state is fully formed based on the current field values.

The Layout logic is not aware of the current mandatory state, field accessibility, button states. They are not provided as input based on the current role rights, variant settings or the previous Layout execution.

The Layout logic only provides the extra rules to apply on the form based on the data of the current row.

Keeping this principle intact, if we are to allow setting collapsed/expanded status of sections to the Layout logic, every time the Layout logic would fire, the sections would re-collapse or re-expand based on the Layout logic, even if the user would have manually collapsed or expanded certain sections.

To get a better idea of how to approach this, can you share some more examples of use cases for this?

Hi ​@Anne Buit my example follows the rules of the layout, as the row already has knowledge of what has been read or not. So it can be detected based on the row. As to the other points:

• Collapse or not should be based on current row information, and in my opinion only when (re)loading the screen, not based on what is entered at that moment. I think any other scenario would make the UX really terrible. 
• I don't quite follow the rights comments..  Mandatory state cannot be set via rights right? Accessibility and visibility I follow, but don't think they interfere with applying layout logic in this way. 
• I understand the point of manual collapse/expand, but this is always in combination with the goal. I don't see scenario's where you would apply this type of logic and will enter a situation it would unwittingly interfere with the user experience of a user. 

I see mainly very powerful options in the areas of:

• Validation of 'changes' or 'differences' (see my first example)
• Role based (roles in the client app) importance of sections.. (here I can imagine a manual expand would preferably be maintained)
• State based importance of sections. 

And let's not forget that there is still a developer who always has to think about what he/she is delivering and therefor chooses to leverage a function like this when it suites.. The platform has more options that can be very bad when used wrongly :)

Hi Freddy,

Given that my Layout logic does the following:

if @has_differences = 0
begin
    set @differences_section_expanded = 0; -- Collapsed
end
else
begin
    set @differences_section_expanded = 1; -- Expanded
end

When there are no differences, the Layout will collapse the section.

However, when (as an end user) I expand this collapsed section, will any subsequent Layout call collapse the section again?

And if not, when will the GUI start listening to the section indicator of the Layout again?

If I’m not allowed to expand the section, it may be better to simply hide all the fields in the section using the Layout instead.

These challenges do not occur with the current Layout settings, which set things to mandatory, read-only and hidden and such as they are simply applied on top of the existing form settings. There is no further ‘user state’ that needs to be taken into account, contrary to the ‘user state’ of the current section expansion.

Hi ​@Anne Buit ,

Well, looking at my list of options, for option 1 it's kind of wanted that the layout collapses the section again from a functional view-point. Options 2 and 3 are more open to discussion. Perhaps this should be a setting if it should listen to the UP (user preference) as the GUI knows the user opened/closed the section. 

The option to hide all fields is understandable, but from a functional point of view not always wanted. In my case the user has an option to add values manually. if they do so, the section stays open. If not the section is closed again. If it's better to hide, I think you should always hide. For me collapsible segments is more for focus and to steer importance by opening up the at that point in time the most important section based on for example status, role, a difference.  

I do understand the conflict between UP and Layout. I think it should be a setting. The 'correct' answer is functional and I can think of scenario's you want to overrule the manual opened/closed section and I can think of scenario's where UP supersedes over the layout.