more power for the Back button

[Georges]

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.

Suggestions

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.

[OlivierOzoux]

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 )

[Steve]

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.

[OlivierOzoux]

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]

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.

[Georges]

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.

[jkirchheimer]

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]

a few kilobytes will not cause any memory issues

[Kebap Benzin]

Another case where the back button would be useful is on the file browsing...
In most cases you use the "info" to go into things and the "back" button to get out of them.
It would be useful for finding your samples as well.

[lozzie]

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.

I would prefer that only the Pads button took you back to the Pad trigger screen.

I understand the wish for consistency, but I wouldn't want yet another screen added to a cycle of button pushing, if there is another hardware button that already takes you to that screen. A dedicated hardware button at that.

[lozzie]

Another case where the back button would be useful is on the file browsing...
In most cases you use the "info" to go into things and the "back" button to get out of them.
It would be useful for finding your samples as well.

When browsing files in the BB there is already a back button displayed on the touch screen though.

If the the hardware back button was used for this purpose (as well as, or instead of) it might introduce more confusion due to inconsistencies in my opinion.

If 1010 Music had labeled the back and info buttons "F1" and "F2" or buttons "A and B" for example, I'm not sure that people would perceive there to be a problem here.

I think the navigation of the BBs functions is well thought out considering how powerful it is. Inconsistencies with the behaviour of the back button is not something I had noticed until it was mentioned.

If it is problem to be solved, there is a potential of not pleasing everybody, doubling up on routes to certain screens, and/or introducing more screens to a cycle of button presses unnecessarily.

[lozzie]

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.

I would find this less ideal than the present behaviour of the Back button.

At the moment the Back button takes you to a specific page depending on the mode you are in.

Changes to that behaviour to make it more consistent across modes is one thing that may be worth looking at.

But I would not want waste a hardware button that cycles back through screens based on how I have historically been purposefully, randomly or accidentally navigating forwards through the BB.

This might be the behaviour that I would want in something as vast as a file or internet browser. But I don't think the small amount of screens in the BB UI needs this.

The file browser in the BB offers a back button on the touch screen that behaves as you describe, which makes sense to me .

Personally, I would prefer that the hardware buttons took you to a specific place depending on where you are, not where you were.

I don't want to sound negative and I appreciate that what would not suit my work flow may suit yours. But if this behaviour was implemented, I would prefer the option to switch it off.

[Georges]

If 1010 Music had labeled the back and info buttons "F1" and "F2" or buttons "A and B" for example, I'm not sure that people would perceive there to be a problem here

That’s precisely the core issue and the hardware button in question just so happens to be named the Back button.

Ask yourself: how often do you actually push the Back button on the blackbox? Have you ever found yourself in situations where you had wished it to perform another action than its current?