1- MaplePrimes - Questions, Posts, help, musings, answers ... all things Maple and math

Ask a Question

Create a Post

Featured Post

3437

Are there alternatives to Ribbon-Based GUIs

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

Yes, there are many alternatives to ribbon-based GUIs. The ribbon UI, while popular and effective for many applications (especially those with a large number of functions like Microsoft Office), isn't the only way to design an interface. Here are some common alternatives:

Traditional Menus and Toolbars: This is the classic approach seen in older software. A menu bar at the top provides access to all commands, while toolbars offer quick-access icons for the most common functions. Many applications, especially on Linux, still use this model. A variation is to allow the user to customize their toolbars.
Command Palettes: This is a popular approach in modern text editors and IDEs (like Visual Studio Code or Sublime Text). The user presses a keyboard shortcut to bring up a search bar that allows them to quickly find and execute any command in the application. This is highly efficient for power users who know what they're looking for.
Contextual Menus (Right-Click Menus): These menus appear when a user right-clicks on an element. They present a list of actions relevant to the selected item. This is a very common and intuitive way to provide functionality without cluttering the main interface.
Sidebar or Panel-Based Interfaces: This design uses a vertical panel, often on the left or right side of the screen, to display tools, options, or settings. This is often seen in design software, where the user can access layers, brushes, or properties from a dedicated panel.
Hamburger Menus: A three-line icon (the "hamburger") that, when clicked, reveals a menu of options. This is a very common design in mobile applications and is increasingly used in desktop web applications and software to save screen space.
Floating Toolbars/Heads-Up Display (HUD): These are toolbars that appear near the user's cursor or the selected object. This keeps the tools close to where the user is working, reducing mouse travel. This is a common pattern in creative applications like 3D modeling or video editing software.

The best choice depends on the type of application, the target user, and the platform. For applications with a huge number of features, a ribbon can be a good way to organize them visually. For applications with a more limited set of functions, or for a mobile-first design, a simpler approach is often better.

Nothing exciting new but the insight that Maple's GUI is a hybrid that adds to the ribbon other concepts. Since the Maple ribbon is young and not part of the training data set, I asked for a better GUI for Word instead:

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.

So, instead of just one idea, here are three different approaches that could improve the Word GUI for different types of users:

This GUI would learn from your habits. Instead of a static ribbon, the tabs and icons would change based on what you're doing.

Smart Ribbon: The ribbon would automatically switch to the most relevant tab. For example, if you highlight text, the "Home" tab would expand with formatting options like font size, bold, and color. If you're near a table, the "Table Design" and "Layout" tabs would appear instantly.
Contextual Command Palette: A simple keyboard shortcut (like Ctrl + K) would bring up a search bar in the middle of the screen. You could type "insert table of contents" or "change line spacing" and the command would execute without you having to hunt for it in the ribbon. This is a much faster option for power users.

This approach would strip away everything that isn't essential for a focused writing experience.

Floating Toolbar: When you start typing, the entire ribbon disappears. When you highlight text, a small, floating toolbar with only the most basic formatting options (bold, italic, font size, bullet points) appears right next to your cursor.
"Focus Mode" on Steroids: A dedicated "Focus Mode" would hide all menus, toolbars, and even the scroll bar. You would see only your document on a clean background. All advanced functions would be accessible through the command palette or a single-click button that temporarily brings back the full ribbon.

This design would let users build their own ideal workspace.

Customizable Side Panels: Instead of one giant ribbon, the GUI would be made of modular side panels that you could dock, undock, and resize. You could have a "Styles" panel on the left and a "Review" panel on the right, or a "References" panel that's only visible when you're working on a bibliography.
"My Tab": Users could create their own custom ribbon tab called "My Tab" and drag and drop their most-used commands into it. For example, a student might have "Footnote," "Citations," and "Table of Contents" all on one tab for easy access.

Each of these designs solves a different problem with the current ribbon. The Adaptive Interface helps you find what you need quickly, the Minimalist Interface promotes focus, and the Modular Interface gives you complete control over your workspace.

The highlighted passages point to areas that have been mentioned already in many comments on the GUI. However, there is one more that really stands in the way for me to work with the new GUI. It could be summarized as "Too many clicks". The former GUI (less intuitive, IMO) was in this respect much more optimzed for productivity.
For example, inserting a text passage or putting the cursor into a text passage implies that the user most likely desires formating options. With the new GUI it is required to click on the edit tab (after having clicked on the insert tab or even more clicky with the quick access bar, which is for this use case not really quick).

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!

August 09

5 0

Read Full Post

Featured Post

John May

3061

The Noperthedron

A convex polyhedron with 90 vertices recently claimed to be the first known without the Rupert property

A polyhedron is said to have the Rupert property if there is a way to cut a hole through it so that an identical copy of the original polyhedron can pass through it. For example, you can see that the cube has the Rupert property in the following plot.

P := plots:-polyhedraplot([0,0,0], polytype=hexahedron, style=line, color="DarkBlue", axes=none):
Q :=  plots:-polyhedraplot([0,0,0], polytype=hexahedron, style=line, color="Gold", axes=none):
plots:-display(Q, plottools:-rotate(P, Pi/3, Pi/4, Pi/8), orientation=[0,0,0]);

The edge-on view of the yellow cube shows exactly the hole you'd need to cut through the blue cube so that a cube of the same size can pass through.

There was previously no convex polyhedron known to not satisfy the Rupert property (which is not to say that all known polyhedra do satisfy it, just that none had been proven not to). But a very recept preprint submitted to the ArXiv https://arxiv.org/abs/2508.18475 constructs a polyhedron the authors call the Noperthedron and they claim the answer to the question "Does it have the Rupert property?" is a resounding "Noperthedron ".

The paper gives a construction of this polyhedron, and it is easily built in Maple

R__z := alpha -> Matrix([[cos(alpha),-sin(alpha),0], [sin(alpha), cos(alpha),0],[0,0,1]]):

C__1 := 1/259375205 * <152024884, 0, 210152163>:
C__2 := 10^(-10)*<6632738028, 6106948881, 3980949609>:
C__3 := 10^(-10)*<8193990033,5298215096,1230614493>:

Cyc__30 := [ seq(seq((-1)^l*R__z(2*Pi*k/15),l=0..1), k=0..14) ]:
# these are the 90 vertices of the Noperthedron
L := map(convert, [seq(M . C__1, M in Cyc__30), seq(M . C__2, M in Cyc__30), seq(M . C__3, M in Cyc__30)], list):

# To actually draw the polyhedron from the vertices, we need to construct the polygons for the faces
H := ComputationalGeometry:-ConvexHull(L):

# A triangulation of the Noperthedron, which is almost okay: all faces except the top and bottom are not triangles
P := [seq((L[x]), x in H)]:

# remove the top and bottom triangles
R1,Q := selectremove(p-> {p[1][3], p[2][3], p[3][3]}={C__1[3]}, P):
R2,Q := selectremove(p-> {p[1][3], p[2][3], p[3][3]}={-C__1[3]}, Q):

# merge the top triangles
T := [map(p->p[1..2], {map(op, R1)[]})[]]:
ht := ComputationalGeometry:-ConvexHull(T):
Tp := [seq([p[], C__1[3]], p in T[ht])]:

# merge the bottom triangles
B := [map(p->p[1..2], {map(op, R2)[]})[]]:
hb := ComputationalGeometry:-ConvexHull(B):
Bp := [seq([p[], -C__1[3]], p in B[hb])]:

# the complete polyhedron:
NOP := [Tp, Q[], Bp]:

plots:-display(map(p->plottools:-polygon(p), NOP), axes=none, size=[1600,1600], scaling=constrained);

August 27

5 1

Read Full Post