Houdini 20.5.300. Default settings without any hotkeys and addons. I assign a key to any shelf tool. The hotkey works. If I switch to another keymap and then switch back to the one where the binding was created, the hotkey cannot be found because it is saved without a label and description, as evidenced by analyzing the file Houdini.keymap2.overrides:



Additionally, unlike in Houdini 20, it is now impossible to add default hotkey symbols for tools in any way. For example, h.pane.gview.tool:my_shelf_tool could be created in Houdini 20 by adding them to the config/Hotkeys folder in your package. As a result, the hotkey symbol with a description and label was available for any keymap and could be easily found in the hotkey editor. In Houdini 20.5, this is not possible.

I've already submitted an RFE. However, I'd like to discuss this topic further.

I've reported it since 297. Sad to know it's still not fixed

Should this be RFE or Defect?

LukeP
Should this be RFE or Defect?

This is broken hotkey functionality that used to work fine. How can one use a program if even the hotkeys don't work properly?

alexeyvanzhula1984

LukeP
Should this be RFE or Defect?

This is broken hotkey functionality that used to work fine. How can one use a program if even the hotkeys don't work properly?

My point exactly. RFE is request for enhancement. What you described is a defect. I would create a bug report not RFE.

I’m sure that SifeFX wants to make the software more stable.

Out of habit, I call them RFEs, but I actually mean bug reports

alexeyvanzhula1984
Out of habit, I call them RFEs, but I actually mean bug reports

I’ve noticed you posted a few videos on youtube with the problems in Houdini 20.5. Maybe have a thread here with links to those videos and reference to bug reports. I’m assuming that SideFX product / leadership team is watching these threads. Those types of things don’t always trickle up and I agree they are show stoppers in some cases. Ultimately no matter what great features there are in the software, if it’s not stable - no one will use it.

LukeP

alexeyvanzhula1984
Out of habit, I call them RFEs, but I actually mean bug reports

I’ve noticed you posted a few videos on youtube with the problems in Houdini 20.5. Maybe have a thread here with links to those videos and reference to bug reports. I’m assuming that SideFX product / leadership team is watching these threads. Those types of things don’t always trickle up and I agree they are show stoppers in some cases. Ultimately no matter what great features there are in the software, if it’s not stable - no one will use it.

I have sent bug reports with links to these videos.

And I don't really want to create a separate topic because such topics get closed by administrators.

https://www.youtube.com/playlist?list=PLktqXrNHKHgcXLjM9Jup0z3a5b9AeAV9o [www.youtube.com]

Hope SideFX is listening

I've noticed ongoing requests for UX improvements in Houdini for many years, but it seems that instead of enhancements, we're seeing a degradation of existing features. A significant issue is the Hotkey Manager. Let's break down why I consider the changes to the Hotkey Manager a degradation with some examples.

1. The 20.5 release no longer supports the old file format for hotkey overrides (v1). Now, users must manually convert their shortcut overrides to v2 using Python. This raises the ongoing debate about whether Houdini requires development knowledge. At this point, it's clear that development knowledge is necessary, as there is no UI for converting v1 to v2 overrides. This shift essentially turns Houdini into a development IDE for working with 3D, requiring users to create their own UI for basic tasks.

2. I attempted to use a Python script to convert my overrides from v1 to v2, but it didn't work for me due to the lack of documentation on how the keymaputils.importV1KeymapBindingsToKeymapFile function operates. The only available information is in this forum thread: https://www.sidefx.com/forum/topic/97007/?page=1#post-426749 [www.sidefx.com]

3. There is no indication for users that they need to convert their shortcuts from the previous version.

4. I managed to manually re-enter all my shortcuts, which took me a full day. Some shortcuts don't work as they did in the previous version, requiring further investigation on my part to debug the issues.

5. The Hotkey Manager UI has been updated, but with several degradations. Searching for commands is now more cumbersome. You must use an asterisk (*) in the first filter and enter a command name in the second. Previously, you could simply type the command name in one input field, which was much more intuitive.

6. If you enter a query only in the second filter to find a command, it won't work because the UI requires you to select a Context in the left panel first. The overall concept of having contexts is questionable in terms of usability. If you ask users why they open the Hotkey Manager, few would say they want to manage Contexts; they usually just want to find and change an Action shortcut.

7. The Actions panel does not display information from the keymap.override file, such as Label and Description. As a result, the names for all custom commands are empty, which looks very odd. It seems doubtful that this dialog underwent any thorough QA testing.

8. The default state is not optimal. Why isn't the "All Actions" option selected by default in the Context panel, allowing users to filter all commands more easily?

9. The overall categorization in the Context panel appears disorganized. Having a Houdini section within the Houdini application seems redundant. It needs more attention and reorganization.

10. The Hotkey Manager doesn't retain its state between sessions. If you hide the keyboard or the Context panel, they will reappear upon the next launch.


Here are some simple improvements that could significantly enhance the user experience:

1. Automate the conversion from v1 to v2 so users don't have to handle it manually.
2. Add an "All Actions" item for the Context panel selected by default.
3. Save the UI state between sessions to ensure it remains persistent. This way, users can hide the keyboard and Context panel and focus on filtering Actions instead.
4. Fix the issue with empty items for custom commands.

With these changes, the interface would allow users to simply start typing in one filter to find the command they need, which is what most users are looking for.

I honestly have never seen a software dev team just shrugs and goes like "yep, we broke all your hotkeys from previous version. Just deal it yourself."

Even software that requires the users to be very tech-savvy, like emacs, won't do that.

timurproko
I've noticed ongoing requests for UX improvements in Houdini for many years, but it seems that instead of enhancements, we're seeing a degradation of existing features. A significant issue is the Hotkey Manager. Let's break down why I consider the changes to the Hotkey Manager a degradation with some examples.

1. The 20.5 release no longer supports the old file format for hotkey overrides (v1). Now, users must manually convert their shortcut overrides to v2 using Python. This raises the ongoing debate about whether Houdini requires development knowledge. At this point, it's clear that development knowledge is necessary, as there is no UI for converting v1 to v2 overrides. This shift essentially turns Houdini into a development IDE for working with 3D, requiring users to create their own UI for basic tasks.

2. I attempted to use a Python script to convert my overrides from v1 to v2, but it didn't work for me due to the lack of documentation on how the keymaputils.importV1KeymapBindingsToKeymapFile function operates. The only available information is in this forum thread: https://www.sidefx.com/forum/topic/97007/?page=1#post-426749 [www.sidefx.com]

3. There is no indication for users that they need to convert their shortcuts from the previous version.

4. I managed to manually re-enter all my shortcuts, which took me a full day. Some shortcuts don't work as they did in the previous version, requiring further investigation on my part to debug the issues.

5. The Hotkey Manager UI has been updated, but with several degradations. Searching for commands is now more cumbersome. You must use an asterisk (*) in the first filter and enter a command name in the second. Previously, you could simply type the command name in one input field, which was much more intuitive.

6. If you enter a query only in the second filter to find a command, it won't work because the UI requires you to select a Context in the left panel first. The overall concept of having contexts is questionable in terms of usability. If you ask users why they open the Hotkey Manager, few would say they want to manage Contexts; they usually just want to find and change an Action shortcut.

7. The Actions panel does not display information from the keymap.override file, such as Label and Description. As a result, the names for all custom commands are empty, which looks very odd. It seems doubtful that this dialog underwent any thorough QA testing.

8. The default state is not optimal. Why isn't the "All Actions" option selected by default in the Context panel, allowing users to filter all commands more easily?

9. The overall categorization in the Context panel appears disorganized. Having a Houdini section within the Houdini application seems redundant. It needs more attention and reorganization.

10. The Hotkey Manager doesn't retain its state between sessions. If you hide the keyboard or the Context panel, they will reappear upon the next launch.


Here are some simple improvements that could significantly enhance the user experience:

1. Automate the conversion from v1 to v2 so users don't have to handle it manually.
2. Add an "All Actions" item for the Context panel selected by default.
3. Save the UI state between sessions to ensure it remains persistent. This way, users can hide the keyboard and Context panel and focus on filtering Actions instead.
4. Fix the issue with empty items for custom commands.

With these changes, the interface would allow users to simply start typing in one filter to find the command they need, which is what most users are looking for.

Wow. That’s a lot of limitations and step backs.
And no word from SideFX on what happened there.

I wonder why would they do that. This has been a common complaint from many people after looking at 20.5. And core functionality of the software

And no acknowledgement or explanation from SideFX. That’s not typically like them.

Weird that changes like that would be made and advertised as improvements without usability testing or understanding what has been removed.

My assumption was that their focus was on the technology backend rather than the front-end. To save recipes, they created new API calls to capture all the parameters, which was not possible before. A similar approach was taken with shortcuts, using a new JSON format for keymap overrides. This is a positive step, but it usually has many implications and requires extensive testing, which likely didn't happen.

Regarding the UX, they lack a coherent strategy and make strange decisions that result in an interface that looks worse than one from 20 years ago, which they haven't updated in ages. It's best to hope they don't make further changes.

To ensure my criticism is grounded with examples: the middle mouse dialog serves as another instance of poor interface design from multiple angles.

The mission impossible: To design an interface that shows zero useful information yet occupies the entire vertical space of a 4K monitor.

timurproko
My assumption was that their focus was on the technology backend rather than the front-end. To save recipes, they created new API calls to capture all the parameters, which was not possible before. A similar approach was taken with shortcuts, using a new JSON format for keymap overrides. This is a positive step, but it usually has many implications and requires extensive testing, which likely didn't happen.

Regarding the UX, they lack a coherent strategy and make strange decisions that result in an interface that looks worse than one from 20 years ago, which they haven't updated in ages. It's best to hope they don't make further changes.

To avoid being overly critical without examples: the middle mouse dialog is a complete disaster from many perspectives. They would be better off leaving it untouched.

The mission impossible: To design an interface that shows zero information yet occupies the entire vertical space of a 4K monitor without fitting to the vertical space,

That’s interesting. I mean other than a few cosmetic things - font and alignment choices - I love the new MMB panel. It’s look though doesn’t seem to fit the rest of the Houdini at all.

I love the new MMB panel. It’s look though doesn’t seem to fit the rest of the Houdini at all.

I would love to like it, but I have a few concerns:

1. Why does it look different in various contexts? For instance, why does the new Copernicus use the old version instead?
2. Why doesn't it handle basic cases, which I encountered within just five minutes of use (see the screenshot above where panel doesn't show any useful information but utilizes a lot of screen real-estate)?
3. The typography looks bad because:

• The use of progressively smaller text to distinguish information disrupts readability. Previously, color was used for this purpose, which was more effective.
  
• The use of similar text styles for opposing elements disrupts the hierarchy. For instance, they apply the same style to both the header and the subtitle of the value.
  

4. The alignment is very chaotic, with one, two, and three columns and some additions that break the columns, making information consumption harder.
5. The scrollbar appears all the time where in 90% of cases there is nothing to scroll

To me, this appears more like an unfinished prototype than a production-ready feature.

In design, there is a common pattern used to evaluate UX/UI, known as "visual noise" or "cognitive overload." This occurs when an interface has so many competing visual elements that users cannot focus on specific information, resulting in disorientation and continuous scanning without effectively absorbing any information. This describes the new Middle Mouse Interface we received.

There is a whole other thread discussing the UI / Design issues here:
https://www.sidefx.com/forum/topic/96883/?page=1 [www.sidefx.com]

I don't want to split that even further across two threads, but I have to agree with you 100% when you said:

"My assumption was that their focus was on the technology backend rather than the front-end."

I think this is the crux of the matter. It seems to me that Sidefx is stuffed with 'architecture astronauts' who see UI/UX as just a frustrating encumbrance before moving on to the next big technology.

_______
Edit: After coffee and review, yes, that was a little harsh. You hurt the ones you love the most : ).

From my perspective, this is a different issue from what's discussed in this forum thread https://www.sidefx.com/forum/topic/96883/?page=1. [www.sidefx.com] The problem isn't about the inconsistency of pursuing a modern UI/UX. Rather, it's about recognizing that the current UI/UX strategy has led to a situation where, instead of achieving a new, modern UI/UX, we've experienced a significant deterioration. What we had before (though not perfect) worked better than what has been introduced in version 20.5.

Mike_A
I think this is the crux of the matter. It seems to me that Sidefx is stuffed with 'architecture astronauts' who see UI/UX as just a frustrating encumbrance before moving on to the next big technology.

I think that's a bit too grating. I don't think they view UI/UX as a frustrating impediment, they just don't have the inclination nor the expertise, they're architecture engineers not UI designers, after all.

Either way, best to stop psycho-analyzing and focus on what needs to be done with discussions and RFEs IMO.