Skip to main content

A limited part of the screen types we have developed are marked as “available for user preferences” and thus released for end users. Users can select the released screen types via user preferences for a subject and switch to another screen type.

 

However, in the different situations “main, detail, zoom, popup”, the choice of a screen type in our 360 setup does not always lead to desired situations.

 

We would like to model in the SF per situation (main, detail, zoom, popup) which screen types may or may not be available for user preferences in IAM for a subject. The screen types that are offered as selectable for a user in the user preferences in IAM, in the scope of a subject, must respond to the modeled ones in the SF.

 

This provides more flexibility and less unwanted situations

 

New→Open
The following idea has been merged into this idea:

All the votes have been transferred into this idea.
Open→On the backlog

Hi voters!,

We are refining this idea to be implemented. However, we came at the point a decision has to be made regarding the chosen implementation. We came to 3 different ways that we would like your input on. The options are:

  1. A whitelist of screen types per Table in a particular situation (Master/Detail/Zoom/Popup).
    • Every table may have a set of screen types that are available in a particular situation. This allows you to select screen types that are optimized for a situation. (Preferred option by @Frank Junger)
    • New screen types are not available for a table once a whitelist is created for that table
  2. A whitelist of tables per screen type similar to breakpoints
    • Every screen type may have a set of tables that are available based on the screen size. You can imaging a complex screen type may not look as good on mobile as it did on desktop.
    • New screen types are not available for a table once a whitelist is created for that table
  3. / 4. Any option above but then rather a blacklist
    • This means that a given screen type is not available for a Table in a particular situation.
    • Advantage being that new screen types will be available to all tables rather than not be available until whiltelisted for a table in a particular situation.

Do keep in mind that only screen types that are "Available for user preference” are included in this screen type selection list. Meaning, both a whitelist and blacklist will usually not be a long list.

Call to action: All options has its advantages, but to make a decision that you support, we would love to hear your opinion. Please choose an option and reply here. Thanks!

On the backlog→Needs feedback

Hello Mark,

We think option 1 (screentytpes per table) in combination with a blacklist is the best option.

Thanks for your input!, we'll continue with the impact analysis and keep you all up-to-date to any status change
 
Needs feedback→On the backlog

Are there any developments to report regarding this idea?

In Universal, users can now easily enable screen types that will not work properly. In particular, also built-in screens (Copied from base model), such as "Cube", "Chart", whose option "Available for user preference" cannot be disabled in SF.

Are there any developments to report regarding this idea?

Hey Harm, not at the moment. We have successfully released the 2024.2 and are now focussing on adding some very awesome new additions to the platform, so this idea has not yet been planned. Luckily we did get feedback on the preferred implementation of this idea so that will certainly help.

@Arie V, @Mark Jongeling ?

Is this something we can expect in upcoming releases? The original idea is already 4 years old and it has quite some votes now. 

Users can get confused if they accidentally choose the wrong screen type, and because of this we can do nothing more than switch of the option ‘Available for user preference’ for all screens.

 

​@Harm Horstman It is not in scope for Release 2025.1. But I did add it to the User Experience improvements topic, from which I'm sure we'll pull some Ideas for later Releases.

 

Terms & ConditionsCookie settings