The new ribbon style user interface of recent Maple versions is well structured and visually much more appealing than the former user interface. Great for new users. However, I do not use the new Maple version for productive work because it is considerably slower to use: Much more clicks and mouse movements are involved than before, which breaks the flow.

To improve this situation, I thought about customizing the quick access toolbar with menu items that I need all the time. With Maple 2026 this suggestion has become a less viable solution because the quick access toolbar shrunk in size and moved to a screen location with low mouse activity (to get there fast, the mouse has to move back and forth like Speedy Gonzales). The tiny buttons in the toolbar are hard to distinguish and to hit in one go (a golfer might say “it's rare like an eagle”). If you disagree, try to write text and switch to non-executable math (to enter a symbol) and switch back to text and continue writing. Do the same with the former user interface (e.g. Maple 2024) and compare.

As a new suggestion I thought about adding a new tab "My Tab" to the ribbon that is customizable by the user. Here is what I would pick from the current ribbon items

(A subset from 4 out of 10 tabs: The Home, Insert, Edit and Help tab. The latter is less important)

I would probably also add these two items

although they do not fully replace the former buttons from the contextual tool bar

.

I use the above buttons from the former user interface allot in text passages to toggle between text and non-executable math. They are also useful to change the input mode of an empty document block (instead of inserting a new line with the desired input mode and deleting unwanted input lines). These buttons were introduced with Maple 2021 to improve usability, now they are gone and with it the ease of integrating math into text. With Maple 2026, I have to go back to using F5, which now “toggles” between three states (with the drawback that now in 1-D Math no indication of the state of the input mode is available on the user interface).

The above selection of menu items is my selection to work efficiently on textbook style Maple documents composed of explanatory text passages (including non-executable math) and Maple input and output. Other users would probably customize differently according to their needs.

A final remark about the undo function. Most software has undo on a top level. I do not understand why undo is not in the current quick access toolbar.

I strongly hope for productivity improvements that I can stop using Maple 2025.2 for Screen Readers (having the former user interface). Please do something to reduce mouse movements and clicks of frequently used interface functions. There is too much tab switching between the 3 most important tabs (Home, Insert, Edit) and too little functionality and ease of use of the quick access toolbar.

I would be interested to know which menu items other users would select.

I have contacted Maplesoft support with the intend to send them corrupted Maple.ini files (that caused Maple 2026 installation to malfunction) for further analysis.

Before sending I asked whether they were interested. In the email response support replied that they were happy that my problem has been solved. I replied that they apparently did not understand my first mail. Then I got this back.

Hello,

Thank you for clarifying! I apologize for not being more clear in my response.

The issue with the preferences file (Maple.ini) was summarized in the MaplePrimes links that you provided which have been shared with our R&D team. They will be able to investigate the problem further.

Please let us know if you have any questions or concerns.

Best Regards,

XXX(Name removed, Case - 00191471 )
Technical Support Analyst

Apparently I have shared the files already. Not to my knowledge. Without my ini files no one can investigate the case.

For me this answer sounds like an automated AI generated reply. That is not what I expect as a long-time customer and EPM participant (paying full price). Premium products should come with premium support!

In this case I solved the installation problem myself with the help of this forum and wanted to support Maplesoft to make better products. Now I really feel like an idiot. Spending my free time with debugging, offering assistance, talking to a bot(?!?).

Dear upper management and owners:

If you have replaced support staff with bots that do not identify themselves as such, please reconsider what you are doing. Don't squeeze Maple for maximum profit and hide this. Think about your loyal customer base if you have a long-term growth strategy. The value of most companies lies in the people who work for them not in dumb, sloppy working bots. Humans want to deal with competent humans.
And: Do not let AI code Maple. This will lead to sloppy untrustworthy code with definitly more support requests.

I was wondering whether a water molecule exhibits the intermediate axis theorem (IAT) effect.

I was also curious if a tool like MapleSim could be used for simulations, as it is designed with technical applications in mind. (It would have been handy to enter parameters in Angstroms and atomic mass, but MapleSim only provides length in mm and mass in grams for small objects.)  

The atoms of the H2O molecule form an obtuse triangle. An obtuse triangle exhibits the effect when rotated about its intermediate axis (horizontal axis in the image below) provided it consists of equal point masses (more details here) which is not the case for oxygen and hydrogen. 

Building and running a model is quick since geometry and masses are available online. Two molecules are modeled in the attached file with parameters from different sources. The left model in the image below represents the atoms as three discrete point masses without individual rotational inertia. The system's total inertia is derived entirely from the spatial distribution of these masses. On the right, the entire molecule is modeled as a single lumped mass located at the center of mass (CoM), with the molecule’s full rotational inertia tensor applied at that point.

IAT_H2O.msim

Both models are rotating about the assumed intermediate axis at 3 THz (3 trillion rotations per second), which is about two orders of magnitude less than near-infrared light (just beyond the visible spectrum). To generate the IAT effect an orthogonal tiny initial “kick” of 0.001 Hz was added.

Visualizing was not so easy since the models are in the picometer range. It was difficult to locate the molecules by zooming with the mouse wheel (the button “Fit scene” on the 3-D Playback window did not work). Running an animation to visualize the IAT effect was not possible because the display speed could “only” be slowed down by a factor of 2^31 (see A in the image below). However, the slider C to move back and forth in time worked. The time (B) was always rounded to zero due to the very short simulation time span of 1E-10 seconds (i.e. 10 picoseconds).

Export of an animation movie worked better. Over the displayed timespan of 10 ps the molecules flip 2 times back and forth. This corresponds to a flip frequency of 200 GHz.

Time is still not displayed in the movie but that is pretty much all what did not work. Overall, a good performance. Also the numerical results did not show signs of loss of fidelity despite the atomic scale  of the objects and the very short time span.

In reality, the rotation of a dipole results in the emission of electromagnetic radiation, which dissipates energy and decelerates the molecule. How can this damping effect be modeled in MapleSim? Someone has an idea?

The Schatz Mechanism should move like this

However, with the default solver settings it froze after a few seconds in a planar link configuration. To make it run, I played around with advanced solver settings. Here is one attempt that went nuts:

(More solver settings for strange behavior can be found here: Schatz_Linkage.msim)

Some people might find this amusing. Of course, it is less fun when the initial plan was to spend an hour just for fun with a simple model (an hour is a fair estimate for similar simple looking models in MapleSim). The immediate reaction when seeing such simulation results is to blame the software for being either buggy or incapable. In this case, however, this was not the case, but identifying the root cause was not obvious.

The Schatz mechanism is a so called closed-loop mechanism where the links of the mechanism form a loop (the ground in the model closes the loop). In general, building and modeling mechanisms with loops is less straight forward than thought. Without a-priory knowledge or help (either by documentation or software hints) users can quickly find themselves in a situation of desperate trial and error. What was easy with other models can become a frustrating experience with unsatisfactory outcome. This happened to me on various occasions.   

What makes closed-loop mechanisms more challenging?  After resting for a long time on my virtual pile of unanswered questions, it turned out that the model, on top of being a closed-loop mechanism, is ill-conditioned: The Schatzmechanism is an over-constrained mechanism that is only mobile for certain geometric parameters. MapleSim can simulate such over-constrained mechanisms, but this can be a balancing act for the solver.

Who could have known this? A knowledgeable expert might say that users who do not know what they are doing should not use the software. But how to become aware of over-constrained assemblies when building and running a model in MapleSim does not require to be an expert?  In this case the geometry was taken from a reference that sets the length of the ground link to Ö3. Model build, assembly and simulation instantly worked … but not for an extended time span.

In retrospect, everything is clear. Models that do not assemble do not fit together. Models that freeze in motion “jam numerically”. Linkages and joints of closed-loop mechanisms made of infinite stiff components may not fit together in all geometrical configurations. During runtime, after successful assembly, a stiff model can make a simulation sensitive to numerical errors. This does not mean that the user is dealing with a so-called numerical stiff problem that can be addressed by using stiff solvers. In this case, stiff solvers could not prevent sudden freeze or inversion of movements.

The only remedies that work for infinite stiff and over-constrained mechanisms are the ones that work also in real life. By either introducing mechanical play or elasticity in supports, joints and links, the simulation becomes robust. Numerically, for this case where none of the many advanced solver options made a difference, a simple increase of the relative error in the standard simulation settings worked.  This remedy could be described as introducing more numerical play. Interestingly in a completely different approach of animating a Schatzmechanism @one man also needed to introduce “deformations” in his simulation to make it work.

The Schatzmechanism is of little commercial interest and can therefore be shared. Is it a rare case of successful assembly and freeze during runtime or is it more frequent that users run into similar problems? Only MapleSoft can tell, but in the latter case it could make sense that MapleSim supports the user. I see several possibilities for that:

• A more prominent mention in the documentation that kinematic loops require caution could raise awareness.  
• Algorithmically detecting kinematic loops and informing the user that closed loops can be potentially over-constrained in certain geometric configurations.
• (If possible, analyzing the Jacobian in the frozen configuration might give better hints than solver messages during runtime can provide. The attached model gives the hint with MapleSim 2025.1 that the error tolerance might be too tight, but no indication why.)
• Implementing the mobility formula, analyzing closed loops and issuing a warning when the mobility M is less than 1 (meaning no degree of freedom)

The latter option sounds appealing. However, the degree of freedom calculated by the mobility formula only provides a necessary but unfortunately not a sufficient condition for mobility.  For example, connecting a prismatic joint coaxially to another increases the mobility by one but does not add to the mobility of a mechanism. This means that an advanced algorithm must take the orientation of joints into account to determine the effective degrees of freedom. On the other hand, the Schatzmechanism and some other mechanisms have a mobility of M=0 but can be mobile for certain geometries.

Should Maplesoft implement mobility analysis or are CAD tools that offer some sort of mobility analysis more suitable? In my opinion, from a conceptual point of view, it would be beneficial and faster to have this support already in MapleSim before going into details.

Should the user refrain from modeling infinite stiff mechanisms? I do not think so because they are useful in the context of deriving (analytical) forward and inverse kinematics. Furthermore, there are more mechanisms out there that are mathematically, according to the mobility formula, immobile but useful in daily life. The telescopic fork is a prominet example.

Final note for math enthusiasts:

The Schatzmechanism (invented by Paul Schatz) is a byproduct of the inversion of a cube. Recalling that the diagonal of the unit cube is Ö3 gives a hint of why the Schatz mechanism becomes mobile for this parameter. Also related to the inversion of a cube is the oloid: a solid with a developable surface that touches with its entire surface a flat surface when rolling. The oloid and the Schatz mechanism are closely related, which can be appreciated from this video.

I was wondering whether MapleSoft has opted for an outdated concept. Here is Gemini's answer:

A "better" GUI for Word is subjective, as different users have different needs. The current ribbon interface is great for discovering features, but it can also feel cluttered.

With the former GUI (having a larger quick acess bar) and a tool bar (in red)

only one click was required with substantially less mouse movement.

Personally I would switch to the new GUI with the following improvements

• a quick access bar that is customizable
• a smart ribbon that switches to the edit mode tab when the cursor is placed on editable text or a new text/input/document block is inserted

Having the functions that I use most frequently available in the quick access tool bar (highlighted in yellow) would allow me to minimize the ribbon with the same productivity and even more screen space as before.

Keyboard shortcuts that differ from standard OS shortcuts are not a viable alternative for me.

Overall, the direction with the new ribbon seems to be right to get new users productive faster. It seems to be a good choice without clear alternatives, and its graphical design aligns much better with the core values Maple provides.

However, becoming productive fast does not mean that the productivity is high. From this perspective the former GUI is not outdated yet. The workflow with it is much faster and more focussed on math and code.

Perhaps MapleSoft has solutions that will make the new GUI even more productive than the former GUI. This would be great!