A short summary is: on a MacBook, I moved a toolbar out of the main application and dropped it to the far left of the screen; this covers up the ‘dotted’ control widget for the toolbar, which makes it difficult to move the toolbar back into the MillMage main window. One solution: restart MillMage and the moved toolbar’s control widget will be visible.
I also describe an enhancement I’d like to see made to MillMage … because there are far too many buttons that are exposed. New users become overwhelmed with the number of tool buttons; more experienced users become annoyed because valuable screen real estate is devoted to toolbuttons that are only rarely needed.
Does anyone else think that too many toolbuttons make for a cluttered and more difficult-to-use UI?
What do you suggest they do with the “rarely needed” tool buttons? Is there some indication which tool buttons qualify as “rarely needed”? “rarely needed” may mean something entirely different to me than it does to you. Whose preferences take priority?
If not a trick question, definitely a difficult one.
No, definitely not a trick question. And, there are some readily-available solutions, which I describe on the MillMage feature request site.
You don’t want to eliminate functionality, or to make it difficult to get to the buttons (or menu entries) to execute the various functions represented by the toolbar buttons. What I think is needed is a way to hide the toolbuttons until they are needed.
This is relatively straightforward to implement using a QTreeView or using one of the Qt-based ribbon toolbars that can be found on github. And, yes, I’m speaking from many decades of experience. (I’m a now-retired developer of electronic CAD tools and have used Qt since the early 1990’s.)
Again, you don’t lose any functionality. But, there is a downside: you have a couple more mouse clicks needed to get to the toolbuttons that aren’t commonly used/needed. I think this is a very reasonablw tradeoff, esp. for the new users who might find themselves overwhelmed with buttons.
At the very least, the bug that allows a movable toolbar to have its ‘handle’ placed outside the computer’s screen should be fixed. But, I’m hoping that the UI developers might go a bit further…
You asked a question that I didn’t answer: who gets to decide what toolbar functions are visible and which ones aren’t. The answer is: the user decides.
If a ribbon toolbar is used, when the category/menu entry is selected by the user, all of the toolbutton entries that fall under that category are displayed (and other, unrelated buttons are hidden). Hence, you only see those toolbuttons that are pertinent… but none of the toolbuttons go away.
If a hierarchical TreeView of toolbuttons is used, the user also gets to choose which set of toolbuttons are displayed, but the user has the opportunity to display buttons for multiple categories simultaneously.
No functionality is lost with either approach. The user may need extra mouse clicks here or there but, in my experience, this isn’t a hindrance. It’s simply the price you have to pay for a cleaner UI.
MillMage is getting new functionality: pages with associated capabilities, new layer functions, etc, etc. If a new toolbutton has to be created for each of these new functions, the UI will become even more busy. Seems prudent to me to put technology in place that allows more growth and, at the same time, declutters the UI a bit.
You would be surprised how often we see users having trouble finding/using a stacked dropdown like this. The main constraint on the UI is resolution - 1080P is the minimum we test for in MillMage, and there’s only so many pixels to go around.
We have plans for customizable toolbars and more context-aware UI in the future, but we’re unable to provide a timeline as for when that will reach public release.
Thanks for the message and a bit of insight into the plans for the future.
Regarding the stacked shapes toolbar. I think this is helpful, though it did take me a moment to figure out that this was available. I have a fair number of pixels on my MacBook (thank you, Apple) but I also have “old eyes.” The itty bitty blue triangle in the lower-right corner is a bit too itty bitty, I think. Personally, I think you’d get better results if you added a shaft to the arrowhead. You know, a shaft that extends from the lower left to the upper right a bit. I’d have it end about, say, in the middle of the square or what have you. I also think the blue is a bit subdued. I think you’d get a bit more notice if you made the arrowhead and shaft a more vibrant fuschia color. Just my opinion… but I think a bigger, brighter arrow would catch the attention a wee bit more. (And, I don’t think requires any more pixels.)
I have some experience building UI’s that have context-aware (dynamically configurable) menus, etc. I know some tricks that can make the process easier. If you ever want to discuss specifics, send a message. (I assume you can get my email from your forum. If not, you know where to find me.)
I see all your suggestions as having merit. Qt is not on my resume’ of experience, but programming is programming. Keep in mind that Lightburn is up to v2.2 and MillMage is not even v1.0 yet. This means we have to be patient and let them develop the whiz-bang features first, then smooth it out.
No worries. Just trying to be helpful. And, I know from experience that the path is smoother and quicker if you start out with flexible, growth-oriented data structures, etc, right from the get-go. Refactoring code might be fun for some but it doesn’t hold appeal for me any longer.
One of the problems with removing buttons is that you’ll eventually discover you need it. Worse, you’ll go looking for it and can’t find it, and we get a support email. (We have Beginner Mode in the software, which hides a bunch of lesser used or advanced features, and this is a constant occurrance)
For the next iteration of both LightBurn and MillMage, I’ve added ‘folding’ buttons:
This makes the ‘Arrange’ toolbar dramatically shorter without removing functionality, and makes the overall interface less overwhelming for new users. It also makes those functions more discoverable, since moving the mouse over those buttons automatically opens the ‘drawer’, and there’s a label on each button along with a general label at the bottom.
I expect a complaint or two, but the long version of toolbar remains untouched, so hopefully the transition is painless.
We’re working on other things to reduce the clutter, but doing so without breaking everyone’s muscle memory is tricky.
Before I say anything else, I want to commend your effort. I think this could reduce the clutter in the UI without loss of functionality. I do think it’s to your advantage to adopt some sort of visual indicator for these hierarchical toolbuttons. That is, draw a blue arrowhead as you’ve done elsewhere, or maybe provide an underline of a certain color. (I think the underline is easier for someone with old eyes to see… like me.)
Now, what you’ve implemented is a tree/hierarchy of toolbuttons, which is along the line of my original request. From what I can tell, it seems likely that you would only allow a single level of hierarchy versus the many levels of hierarchy possible with a QTreeView-based design. Personally, I think there are benefits to a QTreeView-based approach but maybe these benefits won’t matter for many of your users.
From your video, it appears that the lower level is exposed with (only) a mouse-over event vs a mouse-hover or mouse-click. Personally, I would prefer a mouse-hover or mouse-click even vs. the automatic expansion of a mouse-over event. If you could make this configurable, I’d guess that a number of users would thank you later on. Also, have you thought about users with disabilities that may prefer to use keyboard operations versus using a mouse? In other words, you may not want to automatically expand the (upper-level) toolbutton when it becomes active; an explicit command to show/hide the child toolbuttons may be preferable.
Finally, to answer the argument that removing toolbuttons will cause some users to complain, I think the complaints will be minimal if all of the functions can be executed via the menu system but only some of the functions are available as toolbuttons. As long as the user has some way to execute the function, I think the level of complaining will be small.
All of the previous functionality is still available in the “long” version of the toolbar. For users with space-constrained displays, this should be a bit help.
I’ve used tree/hierarchy menus before and I generally dislike them because you spend too much time waiting for the menus to open and your brain to register the locations of the things you’re looking for. It’s possible to do them well, but they’re uncommon, and this isn’t - part of what we’re trying to accommodate here is a lot of entry-level users.
All the functions are also available through the normal menus, which are keyboard accessible and screen-reader compatible.
It won’t be hover enabled - that is less discoverable because you have to know to pause. These self-close, unlike menus, so they’re not obtrusive. I’ve played with variations of it for several days, and settled on this, so before you hate it, try it.
I worked for a disabilities software company (Freedom Scientific, JAWS software) and these two meet the requirements. I do not expect blind people to be using lasers, but low vision is a distinct possibility.
Good to know about your eperience w/ software and disabilities.
When I made the suggestion for customization, what I was imagining was how people who have trouble with fine-grained motor control will handle the auto-expanding toolbuttons. For some, I know that tabbing through the various widgets in an application’s UI using a keyboard might be easier than trying to move the mouse to some precise location. A UI that has lots of popups that occur when moving a mouse across a screen can be frustrating.
I like the approach being considered. I don’t think it’s ideal but I do think it’s an improvement. However, I would like it even more if a user could configure mouse interaction with hierarchical toolbuttons:
iuse the current approach of mmediately showing child toolbuttons when a mouse-over event occurs (and hide the children when a mouse-leave event occurs or when a user clicks on one of the child toolbuttons)
or, wait for a mouse-hover event to occur before showing the child menu
or, wait for an explicit mouse-click event on the parent toolbutton
Just my two cents. Ignore it if it doesn’t add value.
This sort of discussion adds a ton of value - we can do our best to develop features and implementations that we think will work, but hearing more sides than just our own makes for better software across the board. Thank you.
Well you have a window tab that hides a whole list of windows. A icons tab that did the same as window tab would be nice, but the condensing similar functions like with boolean assistant does reduce clutter.
