Near unusable abysmal UI/menu protocol design - example: Pre/Post Commands Menu in PLE

Cubase
, , ,
1

This is one thing with Steinbergs core development that absolutely has to stop.

There seems to be a total lack of thorough but basic discretion when it comes to menu design and behaviour… It’s almost like they pick slips of paper out of a hat to decide which menu type/behaviour is going to be used in which part of the program mostly resulting in complete disconnection from what a working user would need.

In this case, The Project Logical Editor

  • Pre/Post Command menus:
    • First of all, the selected name fields are too small.
    • The actual selection menus not only don’t auto-resize based on text length - they don’t resize at all:

It’s just about almost infuriating to be honest.

How does this get passed QC?

preset menu doesn’t remember resize.

PLE has existed for a long time, there are users with 1000s of presets that are tied into macros and vice versa.

Too manage a library of presets, and convert macros into the new PLE pre/post commands system…. It has taken me nearly two weeks of anxiety and blurry vision and moment of anger to work through this absolutely terrible lack UI/UX discretion.

I hope I’m not ragging on just one of the developers here, because I know the gentlemen who created PLE is a genius and I have a lot to thank for - and if it was only one developer who was responsible for just PLE - then I’m actually ragging on the higher-up developers for leaving the workload and certain aspects of it to only one person…

I don’t know, maybe I shouldn’t be so hard regardless of what the development situation was… and I’ve been trying to stay positive that past two weeks……. I just don’t understand how these menus get passed QC. maybe I should fault the beta testers as well.

These menus, the menu type/behaviour and inconsistency throughout the program cause a lot of pain, lost time, frustration, blurry eyesight, anxiety. It’s absolutely just terrible not just UI, but UX. Literally 1/10 on UX. Almost every UI decision is the wrong decision.

please see me posts here as well:

Complete reworking of Project Logical Editor GUI/UX - Cubase - Steinberg Forums

here is another example of a menu that should have been changed a long time ago, It is the polar opposite of what menu type it should be.

MediaBay: Set Up Results Column: PLEASE(!) get rid of this drop down menu + Presets - Cubase - Steinberg Forums

Here is how much better plugin menu presets could be in a modern workflow:

IMPROVE PRESETS + MENUS - static pop-out browser instead of drop-down, save/replace, more - Cubase - Steinberg Forums

2

That is found in numerous areas of Cubase. It’s not unique to just this example. The solution here, and it’s just a guess…is money. Personally, I advocate a more expensive Cubase, but that will never happen. We are along for the ride, and prosumers are in the drivers seat.

3

Yes menu systems/protocols need to be reworked everywhere.

I think as a general rule of thumb, for the most part, momentary pop-up menus should be done away with where applicable. window pop-out side panel browsers, and making more use of right zone with an option to activate contextual link.

The above links are good examples of both these proposed protocols.

4

So, they rework most aspects of the GUI to annoyance of a number of users at least 9 times every 12 seconds but still use menu systems from the early 90s?

5

Personally I hate that right zone can´t be expanded more when in the media tab file names are truncated (why???)

6

Another one is the MIDI CC Lanes

  • no search filter
  • no folders
  • no mouse wheel support
  • have to slow click scroll
  • is an area repeatedly accessed/needed by users
    • should be a always-on-top popup window with list editing/managing features
    • should be able to be accessed via right zone for quick switching
    • should have a quick search command/function where user command executes a pop-up window/context box ready and cued for user to type in what preset they need with search results filtering closest match.
  • Mapped shortcuts 1-16 should be a separate entity in a manager/editor so that they don’t have to be fixed to the first 16 slots.

It’s another example of…… not the right decision making or perhaps, the quickest solution to it not being how it was in previous old versions of Cubase… Because they did “revise” this menu and many others, but again, wrong decisions.

It reminds me a bit of working with video/film people who undervalue how important audio and music is to the quality of their production.

This is one of those areas that Steinberg don’t seem to understand that what decisions/lack there of on menus - is super important… or just don’t understand the users UX from a day in day out minute by minute hour by hour workflow need.

7

Yes, the examples cited above are very frustrating for the user.

8

The menu systems matter. Have the thousands of Cubase users commented on menu systems? no… but they affect everyone from every moment of everyday who use them and that plays in a huge part of the UX and “feel” of a software.

The menu systems, protocols matter…

Every part of the program, whether old, or a new feature being added - needs extreme discretion practiced by development.

  • Menu Types

    • Why is a type of menu being chosen for a part of the program.

      • What type of menu might a user need/find more useful?

      • Does the chosen menu type create unneeded repetition for the user?

    • Does the menu obscure other things the user needs to see when open.

    • Is it a menu of which will list user-created names of which could be long.

    • What features are needed/could be useful for this particular menu

      • ‘Keep Open’ Checkbox

      • Fully resizable / text length aware auto-resize / resize memory

      • User re-position memory

      • Search Filter

      • Collapse/Expand

      • Editing Features: Rename, Duplicate, Delete, Moveable, Save-Over, etc.

      • Cross-Communication protocols to other parts of the program that read this menu/file-system.

        • Ability to communicate changes / refresh lists (example Macro-PLE refresh broken)

      • Is multi-selection needed

  • Textual/Name/Value Fields

    • What size do they need to be.

      • Is it important for users to be able to see the full name/text field.

    • Keyboard-Tab/Modifiers to next text/value-field protocol.

      • What is a logical order of user tabbing to next field.

  • Saving/Loading

    • Utilizing Current Loaded Name for New Save

    • Integrated saving vs OS explorer window saving

Development should have a checklist/matrix on which menu system should be used and why that is exercised for every menu old and new.