Hi Daan,

if I state in the SF that a detail is not visible, the parameter to make it visible is not offered to the context procedure, and the settings in the SF database always win.

That is correct and we decided to keep this behavior intact. If the model says something is not visible, or hidden, or not available, it is indeed unavailable. 

And if you use a Context procedure to show the details when they are relevant, it will be the same to hide these same details if the are not relevant. So changing the behavior would not change anything other than adding confusion.

What you can influence, is by changing the "Context type output” setting in the SF > User interface > Subjects > Links > Details screen. Unchecking the detail there will prevent the reference from being included in the Context logic. It also happens to be the place to influence the visibility of the detail.

Visible details can be hidden using User preferences in both Windows GUI and Universal GUI. 

I disagree with this; “And if you use a Context procedure to show the details when they are relevant, it will be the same to hide these same details if the are not relevant. ”

A car has a gas pedal and a break, I don’t think that you would like to drive in a car with only a break, and only a gas pedal on the highway would also be a bad idea. 

The way it is now, the platform only has a break. 

When I started we had code like this in our application;

If option=1: hide b,c,d,e,f   -- 1 means a
if option=2: hide a,c,d,e,f   -- 2 means b

That was completely unreadable, cleaned up for readability this became much shorter and more readable ( I shortened it here, in reality with the tabs / fields on different lines, the new version was 20 lines instead of 100, here the new version is a little bit longer then the old);

hide a,b,c,d,e,f

declare option_a INT = 1
declare option_b INT = 2

if option = option_a: show a
if option = option_b: show b

But this solution still has one problem; when the loading of the interface goes slow, the user gets to see a,b,c,d,e,f.  While only a,b are relevant in the context.  

It depends on the context and the application, and I think that the developer should have the freedom to decide which of those 2 options fit best in a situation. 

 

This is possibly a difference in thinking is between my thinking, and the Thinkwise “way”.

As a developer I don’t want to “stop and hide”, but to “allow and give through”. My users can have the break, I have the gas pedal, and you build the engine. 
 

Hey Daan,

Thank you for the insights in your use case. I can imagine the Context logic being more extensive than you might want it to be.

The title of the idea is the thing I disagree with, but I can get into having a new setting that indicates the default state of the reference - such as Hidden, Disabled or Enabled. This could be extended to columns, tasks, and other objects.

Shall I change the title to "Ability to pre-set the default ‘_type’ state of references and other objects” or something along those lines?

I think that having both a hidden or visible state, and a default state could become confusing.

If I say hidden, in for example the database layer, I mean hidden, but when it is a key, the key is still included in the export, while for me “hidden” means that ever showing it to a user is a bug. So, it is already confusing. In this case, as example, the platform should not show the key, and remark in the validation that import was disabled for the lack of a key.

For me this concept means that somethings stays hidden, until a positive confirmation of the control procedure. It means that the interface will never show it, until the procedure says, yes do.

I don’t know how to implement it in the current logic of your platform. But creating the possibility to program by enabling, instead of disabling, could be a huge improvement in different scenarios.






 

For me this concept means that somethings stays hidden, until a positive confirmation of the control procedure. It means that the interface will never show it, until the procedure says, yes do.

I get that, if you have 10 details where only 1 is shown based on a condition, this idea would flourish. However, there are also numerous situations where all details should be shown. If we would simply switch the default state to Hidden for everyone; I'm sure we'll get some complaints.

My idea was to change the "Show detail” to be more of an “Available” checkbox as seen for Table tasks for example. This way unchecking this box would definitively hide the detail as it is not available. Then having a separate field next to it that indicates the default state of the detail (up for debate were that place would be). Default state is of course Enabled, ensuring existing applications run perfectlyfine as before, and allowing you to set it to Hidden so you can decide when to activate it in Context logic.

So there will only be one default state per detail, but I can imagine this will become a Model setting; affecting all details in your application. Mixing use of such default state would become increasingly difficult to understand and manage.

Side-idea would be a sort of Business rule engine in which you can declare without any code what detail would be shown in what situation; but that quite a large idea.

Yes,

Business rule engine
-----------------------------
The business rule engine was actually something I mentioned before somewhere else.

The good thing about that concept would be that it could work client side, and would allow for offline usage. But the cases this engine could handle would still be limited. In a lot of cases, providing context settings, in the main dataset, would actually work.

More general
------------------------
I think that your idea might actually not ask for a lot of adjustments. ( Possibly a lot in the code but not in the user interface ). And I believe that your idea as described above aligns with my idea. 

The main problem I see in our application now is that it often happens that the user interface shows everything in case of a network timeout and hides it a second later, which makes everything look unreliable. 

I believe that the option you mention might actually almost be there;
 

Maybe it is already there but it doesn’t add the parameters to the context procedure. I don’t know what this checkboxes do, ... 

It would look like this. 

Greetings,

Daan


 

I just looked up the previous post I mentioned and it is open under “Declarative Layout logic”. Here it is not about the context procedure but about the layout procedure.

So, to come back to your “Business rule engine” side idea, that could also apply to layout logic. And the simplest implementation would be to make the visibility of something in the context, or a field on the form, depend on the value of another field.

That way it would become possible to write a view in which the visibility is defined in fields hidden for the user, but still available for the user interface to decide what to show or not. 

A “small” problem (actually the biggest) would be the lazy loading of the interface; at this moment it is not possible to show something that hasn’t be shown before, when offline. So, the business rules concept would require to load the whole user interface layout at once … which might actually improve speed big time ( I was thinking about posting this as an idea, but I don’t think that this will happen in one year).

All static components could be combined in one file during “creation”, with a much lower server impact during load as result. At this moment loading the user interface the first time gets throttled by our database plan. It would be much faster to just load the whole thing from a file at once. But that load at once version might miss user settings. … It is not “that simple”.

Greetings,

Daan 

​@Daan Heemskerk ​@Mark Jongeling The topic went a bit astray at some point, but I get the issue with Detail tabs first being loaded and then being Hidden. I have seen this on slower networks too, and besides the fact that it shows something the user shouldn’t see, it also gives a flaky feel to the User Interface.

I’ll update the Idea title as suggested by Mark, and set the status to Open for the idea to have a default ‘hidden but available’ setting for objects that can be influenced by Context (and possible Layout) logic.