No announcement yet.

more power for the Back button

  • Filter
  • Time
  • Show
Clear All
new posts

  • more power for the Back button

    The Back button is the blackbox’s hardware button with the highest potential for improvement.

    Inconsistent behaviour. In the Pads mode, it only works for Info screens, it doesn’t even go back to the Pads trigger screen. Why not? In the Seqs mode, at least the back’s stack includes the seqs trigger screen.

    Eternal loops or cycles of backness. Once you push Back within the Pads or Seqs mode, you’re stuck in an eternal loop of backness. It be becomes a sort of redundant Info button moving backwards.

    Lack of function. In the Mix mode, the Back button behaves the same as the Info button. That’s unexpected.

    Finally, the Back button does not work across modes. That’s a bummer. Once you switch modes, there goes your back button history ... The most obvious use case being in seq or mix mode: what was the name of that pad again: Mix -> Pads -> Back, and continue mixing. There are many other such use cases IMO.


    The Back button should be implemented as a stack abstract data type.

    The stack should simply remember a sliding window or fixed number of historical screens __across the device__’s modes through which you can go back until the stack’s empty again or until you stop pushing the back button.

    If the stack becomes full, the very bottom item should be deleted in favour of the latest screen from which you’ve just left.
    Once the stack is empty, there is no more going back.

    How big the stack needs to be is a decision. 4 or 8 steps would be nice - in any case: communicating the size is important.
    Last edited by Georges; 07-27-2020, 12:33 PM.

  • #2
    I've also noticed the behavior of the section button ( PADS/KEYS/SEQS/...) and the INFO and BACK button varies a lot, which makes anticipating what happens from case to case hard to understand.

    Because the number of options that INFO cycles through is generally very small, these is no real advantage to BACK being a backward navigation, and IMHO should always mean UP ( go back to the level above )

    For consistency's sake, the KEYS section should also use the INFO button to switch between keyboards screens. this is the only place where the button is a toggle, and while it might be convenient, it just adds one more special case ( why is KEYS behaving differently from MIX, for example )


    • #3
      The KEYS behavior is intentional. It is far easier (and quicker) to push a single button once compared to pressing two buttons.

      We hear the suggestions around the buttons and navigation. UX is an ongoing discussion and we appreciate your suggestions.


      • #4
        Originally posted by Steve View Post
        The KEYS behavior is intentional. It is far easier (and quicker) to push a single button once compared to pressing two buttons.
        I think you misread my comment. I'm not arguing that pressing the KEYS button to switch between keyboards is not a good idea. I was suggesting that the INFO button should still work ( right now it switches from the piano to the grid, but not from the grid to the piano ) but more importantly, once you introduce a new UI concept, you should try to implement it everywhere it's applicable, so it doesn't stick out as a unique special case.

        So IMHO tapping the buttons should work everywhere you have multiple top-level pages ( as opposed to a primary page with sub pages ) so right now, that would mean KEYS, MIX, TOOLS with MIX being the one most likely to benefit, because in a performance muting is just as important, if not more than adjusting levels.

        (apologies for co-opting Georges suggestion about the back working more like stack, which I like, if only because I'd rather have UI behaviors applied uniformly across the entire device )


        • Steve
          Steve commented
          Editing a comment
          Yes, I see the issue with the INFO button. But continuing to press the KEYS will toggle you back and forth. That is where I was saying it is easier that way. But I hear your request.

      • #5
        There is mainstream argument about the back button: everyone knows the back button from their favorite internet browser. Why opt for an unknown design under that circumstance? Plus, a stack abstract data type is easy and efficient to program in most programming languages these days. It’s a quick win-win.


        • #6
          You cannot compare stuff from your computer with a hardwaredesign, I can see the idea of a history stack that you use the backbutton with, but that leads to 2 issues:
          1. you have to remember what could happens, when you press the button instead of one fixed action
          2. you have to provide memory to store that Information
          1 might be something ppl could discuss, but I personally wouldn’t want them to take away ram from important device features into something like a back history! Everyone is asking for more polyphony, more sample elements in loaded multi-samples etc. reducing the available memory for some more or less unimportant UI stuff is the opposite of what people ask for.


          • Georges
            Georges commented
            Editing a comment
            a few kilobytes will not cause any memory issues