#101

It can’t be that, as sometimes you have to select source bank, scene, then destination scene.

Having 3 columns of numbers is confusing. Let’s just leave it as stateful, it’s programmed that way.

So just keep 1 selector column that transforms between selector types. Seeing their selections beside the label in column 2 will be clear.

#102

As to the PARAM behavior scaling for optimal use in navigation: I really think this is something that just needs to be tested in use with actual interface.

1 Like
#103

The variant on the right is I think close to what you had in mind.
I feel like there is a more elegant solution to this though, especially the fact that it lists explicitly SCENE DST, BANK DST etc. Am not sure I have a good solution to propose at the moment, but:

The variant on the left is maybe a possible direction. You select the numbers for the SCENE and BANK etc. by scrolling just the number (the way currently TT selects the scene from the menu, by basically scrolling the number) without the whole column being visible. In that regard eliminating the column might be more in keeping with the user interaction as it is already established within TT.

I have also included the bottom line space for the scene name.

22 PM
Screen Shot 2017-10-24 at 12.14.22 PM.png1826×490 18.9 KB

1 Like
#104

You can continue longer columns on the version you created for me, and that’s what I had in mind. My layout was abbreviated.

Also, it becomes obvious to me that we will need to remove the entire screen, or most of it to include a dialog for confirmation.

#105

How do you mean?
More than YES/NO?

#106

Apologies for expressing confusion, but in the menus shown in the most recent images it seems like you can save a bank to a scene or a scene to a bank? That seems wrong? I’m sure I’m just misunderstanding, but perhaps there’s room for improvement in terms of clarity here.

#107

That is something that needs to be clarified.
As I said, I think the final design is not there yet.

But a solution would be that if someone wants to save entire bank, that “ALL” should be one of the items included (perhaps at the top?) in the list of numbers of available scenes. And if one selects the “ALL” from scene options then when they get to selecting DST, they only get the DST BANK (and the DST SCENE) is not available.

1 Like
#108

One more variation before I need to go to work.
Trying to simplify.

39 PM
Screen Shot 2017-10-24 at 12.48.39 PM.png1102×610 3.88 KB

1 Like
#109

I am confused too now.

I did not know that multiple banks of scenes (or presets?) can be stored in teletype. Thought those just are folders on the USB drive.

What am I not getting (again)?

#110

Okay, some clarification:

  • The scope of the functionality has not changed since the bottom of the top post.
  • I will use the layout that you see @laborcamp developing, but I have given him examples of the longest entry in the posts, and only mentioned others as it required a longer field in the new paradigm.
  • I am advocating dialog boxes because overwriting a bank with a few accidental clicks could be devestating. I want a clear warning about such activity.

@laborcamp

  • There is no source bank in a save operation (the source bank is flash)
  • Likewise, there is no destination bank in a load operation.
#111

The minutiae of UI development. Nothing that you need to get for any reason.

Edit: If you trust that I will produce something that will achieve the approved functionality that is stated in the top post, then you can safely ignore this thread.

The very first line of the top post should have tipped you off:

Edit 2:

By no means am I discouraging open discussion about the feature, but the dev thread gets hard to maintain if I have to explain an active discussion.

#112

That makes sense :slight_smile: .
Is this last layout feasible though?
If the respective presence/absence of the BANK option is dynamic based on whether the user selects LOAD or SAVE from the first menu, it seems nicely streamlined.

#113

Feasible? Yes! I don’t even think I’d need to refactor anything.

It’s actually quite attractive, I like it! :+1:

Also, note: We’re going to need a “back” icon to squeeze into the selector. Bitmap your heart out! I only say this so that because the text is seeming crowded and a lightweight icon would prevent BACK from becoming hard to see.

#114

ok, cool.

Tell me more about the BACK button.

What situation is it needed for? If someone wants to go back and change their previous choice in the menu structure?
Where do you see this implemented? It seems that there would have to be a “BACK” option on every step, which would be a crazy/cluttered solution. We are looking at 5 step menu choices, would it not be possible to change the NO in the last menu to a BACK button? And change the order so BACK is on top:

BACK
YES

So you can just cycle through the menu options indefinitely, until you are happy with your choices in which you select YES at the end and commit?

I suppose if we want to absolutely be sure that someone is not accidentally overwriting anything, we could add an extra step/screen after they select YES, that just confirms this choice… like “ARE YOU SURE YOU WANT TO SAVE” etc. or something to that effect. Or just one word: COMMIT.

#115

Yep!

What happens if you select the wrong bank and are now selecting scenes from the wrong bank?

#116

You cycle around and change the bank… until you are happy with the settings…

I mean, it really is not that many steps, and you can see all the choices you made at all times. My thinking is that having the button always move forward, and when it reaches the rightmost column it defaults to the top selection, which would be BACK, it cycles back to the first menu choice that still is set to what you have just chosen, so just clicking the button through the choices back to the one you need to alter seems pretty intuitive to me. Don’t know though: might be one of those things that one just needs to see what it feels like in use…

#117

In the “Tentative Menu” in the top post, @tehn notes each back button with “(+<)”, and the context of the discussion at the time was that back was obviously needed when menu-diving.

I really don’t like the cycle-through routine. A dedicated menu option where turning the knob fully left and hitting the button goes back a layer each button press is very attractive compared to punching through.

#118

I see what you mean.
So that each menu has the BACK icon or some such as the top choice…
OK, let me sleep on it. :wink:
Honestly though: that almost seems like more work for the user, since they will need to use the knob AND the button for this operation. And if they need to move back more than one step, that is a lot of fiddling with the knob and button… no?

#119

No. the knob stays in the leftmost position, and the user presses the front button to repeatedly step back through the menus.

The menu will jump to the knob value after pressing back, I think is what you’re missing.

#120

Hmmm.
So, hypothetically, if the user made their choices for all the bank/scene settings, and is at the last/commit menu, and they realize that they should change the source scene, OR better yet, that instead of SAVE they have selected LOAD, and need to change that, then they will have to back through the all the menu sections, which will reset their selected values to the “back”=top of the menu?
Did I get that right, or am I missing something?