"Secondary menus" in Icon-O-Matic and WonderBrush should be changed or improved.

[jstressman]

Icon-O-Matic uses a number of "secondary menus" above different sections of the application, for performing functions on paths, shapes, etc.

Not only do these tend to break form from apparently all the other apps on Haiku besides WonderBrush (which suffers the same problems) in my experience, but the problem is currently greatly exacerbated by #3259 to the point where the app is likely essentially unusable to a new user unless they happened to read a guide before using it that exposes the functionality of those menus, or they accidentally click on them (as I did), or they spot the triggers in an image in the user guide ( ​http://www.haiku-os.org/docs/userguide/en/images/apps-images/i-o-m-overview.png ), which was in fact the only reason I even knew triggers existed in Haiku. (I wasn't a BeOS user and Window and Linux use the vastly simpler and more efficient ALT key alone to focus and unfocus the menu and allow key combos with that same key etc... but I'll leave that gripe for another time)

At the moment Icon-O-Matic apparently relies on the presence of the "trigger" underline to show that they are menus, and the lack of these trigger underlines renders them essentially invisible to the new user. They just look like descriptions of the different sections of the application.

The only other things that imply that they are menus is very subtle gradient behind them, which the menus also use, which is vastly less obvious than the triggers would be, or perhaps that some of them are greyed out if menu options aren't present, which is also not immediately obvious and clear because it goes along with the messages in the boxes implying that the titles are just greyed out because nothing has been added to that section yet... and even these clues are less likely present if you're starting from an existing icon.

This problem is also made even worse by the fact that these non-standard secondary menus cause other problems, like trapping the ALT-ESC menu keyboard shortcut... and trapping it in the Swatches menu, which is by default empty, so that you cannot navigate to the other menus, and none of the menu triggers work.

This very same problem exists in WonderBrush because it reuses this same paradigm. (nonstandard and violating over-all UI consistency, unclear and confusing to new users, and breaks keyboard navigation of menus entirely)

These "secondary menus" should really be redone to either move them to a central location in the main menu, where menu type things generally go (which unfortunately negates the 'proximity bonus' of having them right next to the relevant section), and changing what are now menus to actual non-interactive and unambiguous section titles... or change them to obvious drop down options or something so that any new user immediately and unambiguously knows that there are options available there relating to each section.

I already accidentally attached one mockup I made to the #8758 ticket. I'll attach a copy here as well. I basically added little drop down buttons to show that those were clearly menus or something with available actions (borrowing from a similarly non-standard use in the Magnify application).

I'm not familiar enough with all the available widgets in the toolset to offer any better suggestions or mock-ups yet. :(

I think both these examples are not the way it should be done... using an existing widget in a way inconsistent with its design intention and general meaning to fill a gap, or just function in lieu of a properly done design.

Either the app UI layout should be refactored to avoid the need for such nonstandard UI usage, or an appropriate widget should be found or created to create an unambiguous and consistent way to present such functionality to the user.

[jstressman]

default Icon-O-Matic (no menu triggers visible or currently even possible by default)

[jstressman]

quick mockup to show a hypothetical way the secondary menus could be made more clear

[jstressman]

OK, I've been spending some time in BeOS R5 today to familiarize myself with how things are done in there and what widgets they use etc... and it's given me a good idea how this should work.

So here are two new mockups showing how Icon-O-Matic should hypothetically look.

I believe that switching to this way is not only "more correct", but further solves the other issues with the lack of triggers and visible distinction from being merely section titles, as well as most likely solving the keyboard menu access problem etc. Wins all around.

[jstressman]

Icon-O-Matic with proper pop-up menus for the subsections.

[jstressman]

Icon-O-Matic with proper pop-up menus for the subsections, showing one activated. (by default the option should NOT be highlighted until you actually move the mouse, to match BeOS behavior.)

[jstressman]

hrm... jua pointed out in #haiku...

jua_: Well, the BeBook says about BPopUpMenu: "A menu of this kind can be used to choose one from a set of mutually exclusive states—to pick a paper size or paragraph style, for example. It shouldn't be used to group different kinds of choices (as other menus may), nor should it include items that initiate actions rather than set states, except in certain well-defined cases."

And I think that's basically correct. This use would clearly not match that, and I don't think it justifies a "well defined case" exception, such as how Magnify uses it.

So I'm going to do a new mockup with a bit more dramatic refactoring to do things "correctly". I'll update when it's ready.

[jstressman]

OK, I have some new mockups ready. Unless otherwise noted, see IOMrefactor1.png for the changes.

I refactored the layout to move each section into it's own little layout box like many other apps/dialogs in Haiku have. I moved the menu for each up into the main menu so that we again have a single menu to access with ALT-ESC or whatever.

To compensate for the loss of proximity, we can now access the menu for each section by right clicking in that section (right clicks currently either do nothing at all, or just duplicate a left click in most parts of the app). (See IOMrefactor1-addpath-popup.png, IOMrefactor1-rightclickswatches.png)

As part of this menu change, Swatches is moved into the Style menu, as it's a part of the Styles section functionally, and the Swatches menu specifically can be accessed with a right click directly in the color well (I'm not sure the Swatches functionality even works at all currently? It certainly doesn't look or work like it does in WonderBrush, where I copied the menu layout for it from.) (See IOMrefactor1-swatchesmenu.png, IOMrefactor1-rightclickswatches.png)

I've moved the Shape section to the top left corner, as it is the "main" list around which basically everything else revolves. Paths and Styles are on either side of that, as generally when you click on a shape in the list, you want to see which Path(s) or Style applies to it.

The icon previews were moved into the middle of the left, to keep them near the main lists, but to no longer break the really important ones up.

Transformation and Properties are "grouped" in the lower left, and constrained to smaller sizes, as Properties never grows above the height its shown at contents-wise, and Transformations rarely ever has more than an item or two, and can be scrolled if need be. This gives the main 3 lists more room to expand to list all their contents, namely the Shapes and Paths lists. (The Style list only expands horizontally)

Another proposed enhancement is to add the ability to change the name of any Style, Path, or Shape the exact same way we change file names in Tracker. Two clicks in succession, or F2... this way the names can be changed without having to click on one and then navigate to a totally different section of the app to change it, and then go back to the section you were in etc. (See the Shape list in the upper left of IOMrefactor1-editshapename.png)

I think that about covers it... I'd be interested to know what other Icon-O-Matic users think about these changes, having gotten a feel for the existing layout?

[jstressman]

basic overview of the new layout.

[jstressman]

shows how the menu for a particular section can be accessed by right clicking in that section for quick and easy access.

[jstressman]

Shape, Path, and Style names can be edited in situ the same way names in Tracker are. Slow double click, or F2, or some similar method. (or in Properties still if you want)

[jstressman]

The Swatches menu is moved into the Styles menu, given that Swatches is part of the Styles section functionally.

[jstressman]

or you can access the Swatches menu specifically by right clicking in the color well, like the right click functionality of the other sections.

[stippi]

I am not too happy with the proposed changes. You do have a point when you say you didn't realize those "labels" were actually menus. No arguing with that. Let's try to focus on that problem.

I think your rearranging of sections doesn't make as much sense as the current layout. Paths and styles are global. You have removed the relation between shapes and their transformers. Transformers are not global, but a property of a shape.

That being said, the placement of the Properties list is weird as it is now, since that actually relates to everything else, depending where there is a selection. But you can't fit everything perfectly...

Also, I really don't like how the proximity is lost when moving everything up into the menu. And I regret the huge loss in space efficiency.

Basically, the interface now has that one problem. Once you know that those are menus, everything else is rather Ok. With your proposed fix, you (IMHO) introcude a bunch of other problems: Loss of proximity, logic of arrangement is lost, much additional space needed.

Also, the Swatch menu is actually independent of the Styles. It is an independent control. The options in the Swatch menu (not yet functional) would relate only to those swatches, regardless of where they are used in the end.

Another thing: This use of BMenuBar is not against any style guide of BeOS or how this control is intended to be used. BWindow even has a method MainMenuBar(), that suggests it is even anticipated that a window may have more than one menu bar. Other apps have used this concept, even such big and professional ones as Autodesk Maya.

That Alt-Esc doesn't work in this situation is a bug worth fixing.

In WonderBrush, there are multiple of these menus that have more than one top-level entry. For example "Object" also has "Filter".

In I-O-M, that is nowhere the case. So one thing I'd be OK with is to make the current menus true labels, and add a drop-down menu indicator to each one, but not like the BMenuField one, more like the layers menu in Photoshop, like a dedicated control alias drop-down-arrow or menu symbol. And if absolutely necessary, the main menu can have duplicates of all those menus. That's again how it works in Photoshop. Such a change would be a good compromise IMHO that addresses the original problem including working around the Alt-Esc bug while not introducing new ones.

[axeld]

Replying to stippi:

Another thing: This use of BMenuBar is not against any style guide of BeOS or how this control is intended to be used. BWindow even has a method MainMenuBar(), that suggests it is even anticipated that a window may have more than one menu bar.

There is a SetKeyMenuBar(), maybe you meant that one :-)

In I-O-M, that is nowhere the case. So one thing I'd be OK with is to make the current menus true labels, and add a drop-down menu indicator to each one, but not like the BMenuField one, more like the layers menu in Photoshop, like a dedicated control alias drop-down-arrow or menu symbol.

I'm not sure that makes it that much clearer; I never had any problems identifying the menus as menus, at least. At least in Haiku it's not common to put gradients everywhere, so that might just be me, though :)

Adding some drop down arrow would probably be sufficient, IMO -- I don't see a reason not to make them look like menus, at least.

Other kinds of applications usually don't have the need for so many independent menus, so I always found that use okay even if it's unusual.

[jstressman]

I'll try to make this short, and much of this is my opinion, or come from general usability concepts.

I think the current layout is too compact. The lack of "negative space" or "white space" makes it difficult to visually parse the flow of the program. It's hard to tell where one section ends and another begins, which controls belong to which sections, what even are controls, etc.

WonderBrush actually avoids this to a small extent on the left side by unintentionally having the resize bars serve this purpose. It is the only part of the app that benefits from this that I can see at a glance. The rest is just lots of vertical and horizontal lines that don't really break things up into more functional meta-units. I think WonderBrush's layout is better than Icon-O-Matic, but both I think throw too much at the user in too compact of a space with not enough done to really use layout and white space and so forth to really group things in a way that makes it easily to visually parse and navigate the flow of the different tools and sections for a new user.

As for proximity, this was fixed by allowing a right click on the section itself to perform the functions. This fits with Fitts' Law of creating a larger target, plus making it right on the section itself that you want to interact with. This is followed by the use of double click on an object name to rename it, just like Photoshop allows, so you don't have to navigate away from the object or even the section you're working on, as you currently do, to rename the object you're working with.

I agree that the latest mockup I did is probably using more white space than it needs to. I was just following the style of many other Haiku apps that use the very same spacing for differentiation and functional grouping, and even copied the spacing down to the very pixel from these other applications.

Further, if the Transformers are so closely tied to the Shapes alone, then why don't we add the Transformers menu item next to the Shapes menu item on the same section, and show any applied transformations in the Properties box along with the rest of the Properties of that Shape? This would clear up another section and create more room for the lists of Shapes and Paths, while simultaneously help make the submenus look more like submenus by having multiple entries on one of them.

I'm iffy on that only because I don't understand some of the relationships as well as Stippi and others since I'm just a newbie. Just throwing the idea out there.

It is my opinion that trying to use every pixel of space possible for controls causes a loss of usability on top of aesthetics and that the program would benefit from the application of negative space for logical visual grouping of functions, that the addition of right click functionality would dramatically increase efficiency and ease of use, and that allowing direct renaming of objects would also dramatically increase ease of use and intuitive functionality.

I think if things like this were done, we wouldn't have problems like clicking on File and then moving the mouse right to navigate the menu and having it stop at Options and not go to Style because Style isn't actually a part of the same menu etc. The submenus could clearly and immediately be seen to belong to the list below them, and be seen as menus, etc.

There might be other ways to approach this if a more dramatic refactoring were done, or if there was a true full screen mode that actually extended the functional space all the way to the edge of the screen. But that isn't the case currently.

That's it from me on this issue. Maybe this can serve as food for thought for someone with the skills to implement these changes. I'm done putting time into it.

I appreciate the feedback so far. It's been informative. This is just something beyond my abilities or my understanding of the "Haiku way of doing things" at the moment.

[pulkomandy]

Done in ​https://review.haiku-os.org/c/haiku/+/3122

I went with the initial mockup (just adding the popup menu arrow) rather than the later one with boxes and moving the menus to right click pop-ups. While this is using the controls in a bit of an unusual way as it was mentionned earlier, I think it's still better for discoverability.

[pulkomandy]

Change merged in hrev54535