How to improve 20.2 quick properties window ?

[clair_augsburgerZGWRZ]

In FlexSim 2020 Update 2, developpers have added a new Quick Properties window that appears next to your cursor when double clicking an object:

Here is an idea that I shared with @jordan.johnson:

Expand by default the section showing the parameters of this object's class.

Please find below examples of this idea for some objects:

Processor

Queue

Source

I think that this would help beginners to quickly find the most important settings when double clicking an object.

I also think that this would help users migrate from 20.1 to 20.2. Since in most cases the default expanded section in 20.2 would actually show the same parameters as the 1st tab of the 20.1 properties window.

For example in 20.1 the 1st tab of a Processor properties was showing the setup & process times:

So in 20.2 the Processor section could be expanded by default to quickly show the setup & process times:

You can vote for this idea if you think this would be an improvement, or also comment below.

[SimFlex_support]

And also the new property window should be able to be moved by drag and drop.

[Matthew_Gillespie]

We tried doing this, but decided we didn't like it. The main issue is that expanding the object's "default" panel causes panels to be opened inconsistently and it felt annoying to have unwanted panels expanded.

For example, if you click on these objects in the order Transporter > TaskExecuter > Dispatcher, then the properties open with only the "default" panel open - just like you wanted.
However, if you click on them in the opposite order you get expanded panels carrying over. The Task Executer properties has its "default" panel open and it has the Dispatcher panel open. The Transporter now has 3 panels open.

You almost never want to see the Dispatcher panel unless you're clicking directly on a Dispatcher object. However, if you ever open the properties of a Dispatcher object it will pop open that panel (even if you just wanted to rename it) and it will stay open on other TE objects until you manually close it.

In the end we decided it was a better user experience to let the user decide when they wanted to expand and collapse panels. If you really want the Dispatcher panel open on all the TE objects then you can go ahead and expand it yourself.

[Ben_WilsonADSK]

I found that if you double click and quickly move your mouse, the new properties window will open at the new mouse position. Not what you're looking for, but maybe a workaround of sorts.

[philboboADSK]

Attached (ExpandQP.zip) is a module that adds this functionality to the standard objects (for simplicity, it doesn't affect module objects).

At first, it seems like an improvement when you are just clicking on objects without actually trying to work with this change.

Eventually, as you work with it on real models trying to accomplish real UI tasks, it feels weird, confusing, and annoying.

As Matthew explained, we tested with this during development and ultimately decided that simply remembering what the user expands and collapses themselves worked out as a better interface. Trying to expand and collapse tabs automatically for you ended up being more annoying than simply letting you click on the panels you want yourself.

[philboboADSK]

Maybe if other people try it out, they'll feel differently about it. Try using the module for a while and let us know what you think.

[philboboADSK]

With regards to your comment "I think that this would help beginners to quickly find the most important settings when double clicking an object":

Beginners shouldn't even be double-clicking on objects to find settings anymore. All of the setting are available on the Properties pane when you single-click on an object.

You should not be training your beginner users to double-click on objects at all anymore. The Quicker Properties popup that appears when you double-click is a shortcut for experienced users. For beginners, you should be using the Properties pane.

If you are struggling with the muscle memory of automatically double-clicking on objects to edit their properties, perhaps you should try using the attached module (NoQP.zip) to disable the Quicker Properties popup window.

That will make FlexSim 20.2 work like FlexSim HC 5.3 where all the settings were in properties and double-clicking objects did nothing.

Perhaps using this module for a while will help you adjust to using the Properties window instead of the Quick Properties popup shortcut window. Then, when you want it to behave consistently and you are ready to work with the shortcut popup window as you do in ProcessFlow, you can get rid of the module and use the interface as it is now designed.

[clair_augsburgerZGWRZ]

Thanks for your feedback @Matthew Gillespie.

Actually what you have tried is not exactly the idea that I share in this post:

"Expand by default the section showing the parameters of this object's class"

What you have tried is:

"Expand by default the section showing the parameters of this object's class AND expand any similar panel that was previously expanded, no matter in which object's class"

I agree with you, this behavior is much less convenient.

Back to your example, the Dispatcher, the TaskExecuter and the Transporter don't belong to the same class:

If the Dispatcher panel was previously expanded on a Dispatcher object, why should it also be expanded on a TaskExecuter object ? I agree with you that it does not make sense, since these 2 objects don't belong to the same class, so we don't focus on the same properties.

[philboboADSK]

The Quick Properties popup is the same window shared for every object. Depending on the object's class, different sections will be shown.

It remembers which sections were expanded or collapsed as you bring it up multiple times.

You are proposing that it collapse all those sections and expand just 1 section depending on the object class you double-clicked on?

You want it to not remember what sections were expanded?

[clair_augsburgerZGWRZ]

If I double click on a Source, the Quick Properties popup should expand the same sections that were expanded the last time I opened the properties of a Source.

If I double click on a TaskExecuter, the Quick Properties popup should expand the same sections that were expanded the last time I opened the properties of a TaskExecuter.

Have you tried this: remember what sections were expanded by object's class ?

If you have a module for it, we can test it and give you our feedback.

[clair_augsburgerZGWRZ]

Thanks for sharing this module @Phil BoBo. I have tried it and I agree with you: it's not convenient because it also expands any similar panel that was previously expanded, no matter in which object's class. That's why I think it could be an improvement to remember what the user expands and collapses for each object's class.

[clair_augsburgerZGWRZ]

> You should not be training your beginner users to double-click on objects at all anymore.

That's exactly what I have done so far in my trainings on 20.2. I encourage users to edit properties in the right pane. However, some users still intuitively double click on objects.

For users who always use the right pane, there is another drawback: they spend a lot of time stucked in the bottom right corner of their screen. Not everybody has a large screen and can display all the properties in the right pane without scrolling all the time.

In previous versions, the properties window allowed to work cumfortably in the center of your screen, or anywhere else you wanted to drag that window.

[clair_augsburgerZGWRZ]

> You almost never want to see the Dispatcher panel unless you're clicking directly on a Dispatcher object.

I fully agree with you @Matthew Gillespie.

But currently in the right pane the Dispatcher panel is expanded by default when you click on a TaskExecuter, a Transporter, an Operator...

I think it's better to keep the Dispatcher panel expanded by default for the Dispatcher only, and collapse it by default for other objects.

[Matthew_Gillespie]

@Clair A

I personally have strong objections to remembering expanded panels by the object's class. This is because a lot of the panels are shared across multiple class types.

If I decided to set the color of a bunch of objects in the model I would have to expand the Visuals panel for every class type. Then, once I was done, I would need to collapse the panel for every object type. That is a lot of unnecessary expanding of panels to perform the same simple operation on each object. The current system is much better: I expand Visuals once, click on each object once, close Visuals once, done.

[clair_augsburgerZGWRZ]

@Matthew Gillespie

In this post you gave me 2 examples that are contradictory.

If you expand the Visuals panel on 1 object, you want to see it expanded for the next object you edit, no matter its object's class.

If you expand the Dispatcher panel on a Dispatcher, you don't want to see it expanded if the next object you edit is different than a Dispatcher. However, that's the current way it works.

Should you divide the panels in 2 categories ?

• generic panels shared accross all class types:
  • Statistics
  • Visuals
  • Labels
  • Ports
  • Triggers
• class specific panels:
  • Source
  • Queue
  • Processor
  • Dispatcher
  • TaskExecuter...

For generic panels, they would be expanded or collapsed based on the last time properties were opened, no matter in which object's class.

For class specific panels, they would be expanded or collapsed based on the last time properties were opened for that specific object's class.

[jason_lightfoot_adsk]

I would like to see some indication in the collapsed view (an asterisk, maybe) as to which parameters no longer have the default values so that I can then just expand the ones that are relevant to the purpose (reviewing or adding)

[philboboADSK]

Those two examples aren't contradictory.

In the first example, following your suggestion, the software expanded the panels automatically. Not the user.

Matthew's suggestion is that the software does not ever expand the panels. Only the user does.

If the user expands the Dispatcher panel, then the Dispatcher panel should stay expanded on all objects with the Dispatcher panel until the user collapses it.

If the user wants to change the Pass To on all three of those objects, they can expand the Dispatcher panel once and then do everything they need to on each object without interacting with the expanders at all. If it remembered the panel expansion per class, then the user would likely first collapse the open panel that they don't want, then expand the Dispatcher panel, then edit the Pass To. Then repeat that operation 2 more times. That's 6 clicks on panel headers instead of 1.

Your suggestions are trying to think for the user what they want to do instead of just letting them control it themselves. In our testing of this feature, we found it better to just let the user control the panels' state themselves instead of trying to control it for them. When the software tries to do something for you that you didn't want it to do, it is irritating. It is better to just keep it simple and let the user control it.

As you try to account for different edge cases, your suggestions are getting more and more complicated. Following your latest suggestion, it will become almost impossible for the user to understand what it is doing and why. Right now it works very simply and consistently. The user is control and it does what the user expects. With your ever-increasingly more complicated rules for trying to divine what the user wants, the system will become harder to understand and use because of its complexity.

[clair_augsburgerZGWRZ]

Thanks for your answer @Phil BoBo.

"Your suggestions are trying to think for the user what they want to do instead of just letting them control it themselves." -> No, my suggestion is to show the user what are the most important parameters when they double click on an object.

When you look at the properties on the right, some sections are expanded by default, some other sections are collapsed by default.

Example for a Processor:

The Processor and Output sections are expanded by default, whereas the Input and Ports sections are collapsed by default. It means that you "think for the user what they want to do": users are more often interested in the Processor and Output sections than the Input and Ports sections. I agree with that and I don't think that it's irritating at all.

In the right properties panel, you have decided to collapse or expand some sections by default, based on which parameters you think are the most importants / frequently modified.

I still think that the current 20.2 quick properties window could be improved using the same logic: the 1st time you double click on an object, the software expands some sections by default, based on which parameters you think are the most importants / frequently modified.

[boris_vidal]

For me, the main problem is that we cannot easily compare the objects between them or browse them easily ...

[clair_augsburgerZGWRZ]

Hi @Boris V2,

I recommend to use Property Tables:

Property tables are a tool you can use to better visualize and change the properties of objects in your model: https://docs.flexsim.com/en/20.2/Reference/Tools/PropertyTables/