The new filter menu layout does not have a location for `program_name`, `program_version` etc. In the meeting last week it was proposed that we add a second lane to method filter menus. E.g. when opening DFT, a lane on the left would show program settings and another lane on the left would show the DFT settings. There are some cons with this approach: 1. What about methods that do not fall under one of the 4 menus? E.g. force-fields? How to toggle `program_name=LAMMPS`, if there is no menu for force fields with `program_name` for it? The same problem is present for any entry that outputs `program_name` but does not output any method information like `method_name`. 2. Where do the filter "chips" (the blue filter indicators) go now that there are several menu locations for `program_name`? It would be unnecessarily tricky to keep track of which menu the filter was activated on, and confusing for the user if several `program_name` chips are shown in several locations. Maybe one central location would work here? 3. If we want to show `program_name` options that are relevant for that menu (e.g. `program_name` in the DFT menu would only show DFT codes), we need to add custom additional filters into our aggregation API calls: _"fetch me all possible values considering these X filters the user has clicked **AND** the fact that method_name = DFT since we want to show it in this particular menu."_ This will take a while to implement, since the search mechanism is designed to work with one global set of filters at the moment. I would say we need to discuss how to address these issues or come up with an alternative solution. In the meantime I would simply bring back the old intermediate menu level for "Simulation" for the next release. It could be renamed to something else of course.