My ideas for menu/GUI organization

General Discussion Suggestions
1

As a long-time user who has promoted/demonstrated/installed Avogadro to/for many members of my group, I have a lot of thoughts on how the interface can be better laid out to conform to user expectations, reduce friction/irritation, and help them to find actions.

Though the following is definitely opinionated, I personally think it’s quite logical (naturally, haha) and I would like to see if other users agree. I would especially appreciate it if any long-term users would take the time to look through and voice an opinion, particularly if you disagree!

1 Things being where the user expects

  • This is not easy, as shown by the shifting position of the coordinate viewer over the years, but it is worth getting right as it massively improves ease of use and the first impression for a potential new user.

  • Menu items must be grouped by what they do, not how they do it, as only the first is known to the user.

  • Choosing which panels are visible (as done by right-clicking on the panel titles) should also be doable via the View menu.

  • The Extensions menu contains way too much disparate stuff. It is not clear to the user why the Periodic Table should be next to Calculate, the language settings, and Set Python Path... The Extensions menu should definitely never contain any functionality that is native to Avogadro e.g. settings or the Open Babel stuff, as it implies non-basic stuff and a beginner user won’t think to look there.

  • There is no clear place to go to change preferences, though I think this has been discussed.

2 Locations of functionality relying on Open Babel

Whether a function uses Open Babel or not is irrelevant to the average user. The actions that rely on it are often very different in their purpose, making it non-obvious to the user that they should be grouped together. Moreover, Open Babel is bundled with Avogadro, doesn’t need to be installed via Download Plugins..., cannot be removed, and is thus not really perceived as a “plugin” or “extension”.

Thus the menu options under Extensions|Open Babel should be redistributed to where the user expects to find those sorts of functions:

  • Add Hydrogens, Remove Hydrogens and Perceive Bonds belong in Build as they are concerned with editing a molecular structure and will typically be used when building a molecule; Edit: In fact, they are already there! They just need the old location deprecating…

  • Configure Force Field... and Optimize Geometry are on the other hand concerned with calculations. They should be completely subsumed into the new force field framework. The Open Babel FF should be the default option within the framework, as currently it is Lennard-Jones if no extensions or Python are installed, which does not lead to the results users expect (e.g. #4973);

  • The exceedingly useful shortcut ctrl+alt+o should trigger an optimization with the force field framework, with whatever the currently configured force field is i.e. what is currently at Extensions|Calculate|Optimize

3 Easier settings management

A preferences menu is a common feature of basically applications, so the user will always look for one first in order to change something globally.

There are already a few settings that can be set for the program, but their menu options don’t currently fit anywhere very well. Preferences should be set in one central location, either a) in a Settings dialog that is accessible via either File, Edit, or View depending on the taste of the programmer or b) as individual menu options collected together into an Options menu.

Note that if approach a) was taken, Qt would automatically put the menu option for Settings or Preferences and put it in the Apple menu on macOS, as required by the macOS interface guidelines.

I suspect the options for background colour, projection, and the rendering settings also belong better in a settings/preferences menu/dialog than under View.

4 Split calculations from extensions

One of the most common use cases for Avogadro is quickly optimizing a geometry. The most common functionality should be available from a non-nested menu for ease of use and discovery.

At the moment this functionality, and other commonly used calculations, is buried under Extensions along with a lot of other, non-calculation stuff. It would probably not occur to a first-time user that such functionality is considered an “Extension” rather than core functionality.

Furthermore, the Extensions|Calculate sub-menu only contains Force Fields and is not the correct place to create/submit a Gaussian or ORCA (or xtb now) calculation, so it is maybe misleading in implying a broader scope than it contains.

I thus suggest:

  • Anything to do with calculations should be split off into a new centralized Calculate menu, as I previously pitched elsewhere.

  • The most common functions (using pre-configured settings) should be available at the top level of this menu as e.g. Quick Optimize and Quick Energy so that they are two clicks away, and should have ctrl-alt-o and ctrl-alt-e shortcuts.

  • Anything outside of the “quick” functions should be organized into sub-menus based on level of theory. This is partly so as to advertise to the user what levels of theory are available, but also so that it can be suggested to the novice/naive chemist that certain levels are better than others.

    • This is implied by placing the “quick” options at the top of the list, which establishes the “crude” end of the scale, and then going down from force fields to semi-empirical (if installed) to DFT under Prepare Input (see below) which sounds more labour-intensive and thus more rigorous.

  • Lastly – and on this I am not so convinced – I think the preparation of input files for quantum mechanical calculations also belongs under a Calculate menu. I would place all the current contents of Input under the slightly more descriptive Calculate|Prepare Input sub-menu.

5 Vibrations/MOs/properties should be visible in a panel, not dialogs

Two key reasons:

  • The user wants to see the list of vibrations or orbitals on screen at the same time as the 3D molecule + MO/animation;

  • If this “Analysis” or “Properties” panel is tabbed, different results from the same calculation can be quickly accessed without always diving into the menu.

This was the case for the orbital viewer in Avogadro 1 and it worked like a dream. Sometimes I still use Avo 1 for this exact purpose. The Orbitals tab of such a panel should basically be a replica of the Avo 1 one. I suspect that @ghutchis is working on this anyway and is already very aware of how much it is wished for.

I also think it makes sense to have a tab here for Molecule which contains everything currently under Analysis|Properties|Molecular.... This is where the value totalEnergy of the system from the cjson should be displayed. It should also have editable boxes for the charge and spin of the molecule. This should be the default tab.

When frequencies/orbitals are found the tabs should be opened automatically, as already happens for the freqs dialog at the moment.

A tab can also go here for viewing conformers one day.

The other dialogs under Analysis|Properties should also instead be displayed here as tabs in the panel, but only when they are selected from the Analysis menu.

The panel and the menu should probably have the same name so the relationship is clear, but I would think Properties is more fitting. Possibly Atoms, Bonds etc. should be in a section at the top level rather than hidden in a sub-menu.

6 Clarity of meaning

  • This is extremely important, and I think where Avo runs into problems most is the names of buttons not matching their function in languages other than English. With the rapid development that is still going on it is hard to keep them in sync. This is hard to do anything about, but hopefully it will become more consistent once the interface becomes more fixed. My only suggestion would be to maybe add Help|Report Translation Error to allow non-contributors to report mistakes in the interface separately to bugs.

  • Plugins/extensions should be referred to by one of the two words, not both. This avoids confusion.

@ghutchis I would love to prototype/implement all this myself, but my C++ knowledge is not great :frowning: and the menu organization is not all in one file, as far as I can tell! If you point me in the direction of where stuff is generated, though, I can play around with it. And if I stick to changing only one/a few things per PR, only those ideas with your blessing need be merged.

2

I’ll try to reply to all of this piece-by-piece, but I don’t have a ton of time this evening to get through the whole list. Plenty of good ideas.

Some of the current state is historical. A bunch of the original Avo2 code was done on a time-constrained contract by @mhanwell on a time-constrained basis … they had to write features for a technical audience.

Some of the aspects Re: Open Babel predate the new optimization framework and I just haven’t had the time to clean them out (e.g., you need pybel installed to use Open Babel forcefields). Perceiving bond orders are also generally still better with OB than with the Avo2 code.

BTW, suggestions about how to make the individual rendering settings more obvious are welcome. In Avo1, we added a wrench (gear?) to the row … I don’t think the current system is very obvious / discoverable.

That’s a good idea. Please submit an issue to GitHub.

I’m definitely open to patches.If someone wants to help adapt the Avo1 settings dialog (e.g., with separate sections / icons), or draft the UI files in QtCreator for a new one… I wouldn’t say no.

I would rather not. Personally, I change the background color fairly frequently. I know a few users who change the projection too. So I’m okay with adding them to a “rendering settings” section of a preference dialog, but I’d also leave them on the menu.

Menu organization is largely defined by the particular extension that creates that menu item. So it’s not hard to tweak, but yes it does take some time.

I want to be very careful about window real estate. So while I think this is a good idea – and something a lot of people liked in Avo1 (e.g., load a vibrational calculation = show the vibration panel)…

I want to be really careful about taking up too much window space with tabs.

So yes, the vibrations will go back into a tab (DockWidget) and the orbital table is in the works. But I want to be really careful about how much screen space we use on that right side.

Maybe? Having the ability to open / close the Analysis => Properties sections could be nice. But I don’t think it should be open by default … simply because I think it would take up a lot of screen space. For example, the atoms / torsions / etc. are pretty wide dialogs.

The problem, IMHO is that there are many programs which span “levels” of theory and/or combine multiple aspects. Is CP2K a “DFT” program or a “Dynamics” program? You can run XTB through Orca and AM1 / PM3, etc. through both GAMESS-US and Gaussian. Heck, you can run UFF and QM/MM through Gaussian too.

IMHO, these are better explained in the manual, or when someone is learning what program to use and what type of calculation to run.

My ideal, frankly, is that packages will adopt input generation themselves, so people download the set of plugins they need … rather than a menu with a dozen options either in Avo1 or in Avo2.

If someone can propose a reasonable organization, I’m open to it, but levels of theory doesn’t seem like a good fit to me. Maybe you can convince me, but I’m very skeptical.

Why doesn’t someone take the current list of input generators and try to organize them.

This is perhaps a poor choice of name for the new framework, but as I explained, it’s mainly a placeholder until I can merge in the direct access to the Open Babel forcefields and I can migrate “Optimize” and “Energy” with appropriate shortcuts.

I’ll go through sometime on Monday and make sure I responded more thoroughly.

Preferences / Settings

I think the most useful thing would be to start a thread about sections that can be swept up into a dialog

  • Python path / version / environment
  • Rendering options (e.g., edge strength … potentially turned off completely for older graphics cards)
  • Language settings

etc.

3

Of course. Nothing is a complaint! Just ideas in a desire for 2.0 to be polished and easy to use for any new users, particularly in a non-graduate setting. Avogadro does have the challenge of being the only quality free tool suitable for both a computational chemistry workflow and a digital ball-and-stick model for high school kids.

Fair. Something else that would be solved once Python is a dependency/bundled.

I agree! My suggestion is that when or if the panel is opened, that tab should be the default/always the first tab. The panel itself should only be opened when one of the tabs needs to be displayed i.e. the default main view should be the current one, without the panel. And then other tabs should only be added to the panel when they are opened or, in the case of frequencies/orbitals/conformers, detected.

Absolutely, the size of the panel when displaying other tabs like orbitals would have to be much smaller that those dialogs and only increase when atoms/bonds tabs etc. are opened to adjust as necessary. I pictured the default size of the orbitals window in Avo1 as the default for this panel.

Alternatively, the Molecule tab could just have buttons for Atoms, Bonds, Torsions etc. which just open the current dialogs. But, as is coded in already, it is exceptionally useful to see the bond highlighted on the molecule while clicking it in the table so it is nice if it’s in a panel at the side.

I take your point completely, but I wasn’t actually looking to mess around with the input generators, my suggestion was not to try to group the items in the Input menu, just to move it to make it a sub-menu of a new Calculate menu. There is then no need to try to classify those methods according to level, they all stay together – all I really meant is that the use of the input generators implies a more involved/thoughtful approach than a quick and dirty optimization within Avogadro, so Prepare Input should be at the bottom of the list.

Besides which, the ordering is just an idea, it isn’t critical. The creation of a menu for stuff relating to calculations was the primary motivation, as I think users look for that functionality a lot. I should think basically every single structure drawn gets optimized, for example.

My suggestion of a Calculate menu was actually primarily intended for running calculations in and from Avogadro, where the results will be shown immediately in the app. Thus it is not truly necessary in my mind for the Input menu to be moved at all, it could remain separate and I’d be more than happy with that. My thought was purely that a user wanting to run and ORCA calculation might first look under Calculate, because it’s a calculation, and be surprised not to find it there.

To illustrate, the Calculate menu could simply look like:

Calculate
Quick Optimize Ctrl+Alt+O
Quick Energy Ctrl+Alt+E
Choose Quick Method…
----------------------------------------
Force Field >
----------------------------------------
Extended Hückel (Yaehmop)>
----------------------------------------
Semi-empirical (xtb) >
----------------------------------------
Prepare Input >

The Prepare Input would just open a sub-menu that looks and works identically to the current Input menu. But that option doesn’t even have to be there at all if you’d prefer!

Naturally only functionality that is installed would be visible to the user. But it provides a good home not only for xtb but also for any other current and future plugins that deal with calculating something and returning the result to the user. Yaehmop is presumably another example that would be well-suited to the menu.

Choose Quick Method would just open a very simple dialog allowing to choose between any method/plugin in the menu that provides a Optimize and Energy commands in its sub-menu, and the quick options would then simply execute those commands. This is also optional, the quick settings could just always trigger a FF opt if you prefer. Just nice to give the user choices. That setting could also be put in an Options menu instead.

You’d prefer a proper dialog then rather than just collecting the various setting-like menu options into an Options drop-down menu on the menu bar?