Feature Request: Faster way to edit basic text of a button

[tim-sparkstreet]

Is this a feature relevant to companion itself, and not a specific module?

• I believe this to be a feature for companion, and is not specific to a module

Is there an existing issue for this?

• I have searched for similiar existing issues

Describe the feature

It would be very helpful for my company's workflows (and I'm sure many others who will soon be transitioning to v5.0.0+ and do any work that requires often changing button Text labels) to be able to quickly edit the "Button text string" of the default "Text" element on a button's "Style" tab.

Several possible options in (likely) increasing order of difficulty:

1. Automatically expand the "Text" element when creating a new button or selecting the "Style" tab of an existing button.

Currently when clicking on the "Style" tab, you have to "Select an element from the list above to edit its properties" which I feel like could instead default to automatically selecting and expanding the topmost element in the list, which in most cases would be the "Text" element. I imagine the vast majority of the time most people will be selecting "Text" to edit first anyway, and if not then they're going to have to mouse over and click a different element anyway so at worst it inconveniences nobody and at best saves a click for most.

This alone would halve the extra mouse moves/clicks needed from old behavior and I don't see a downside to implementing it.

2. Move the "Style" tab (or add an option to move) to be physically separated from the "Step", "Feedback", etc. tabs and place it where the "Notes" field currently is (and where it used to be in previous versions). New Buttons should also automatically open to "Step 1" like they used to instead of adopting the previously selected tab from an existing button.

Notes could become a tab with "Style", separating the visual configurations from the functional tabs. It could also just move down to sit in between "Style" and the "Step, etc." tabs.

The current behavior (in v5.0.0+) is that the first screen that opens up after creating a new button is whatever tab you were selected on with a different button, which can vary. I understand the rationale for this when switching between existing buttons (changing step behavior, feedback, or style on several buttons in sequence), but it doesn't seem intuitive for new button behavior.

Here's the old screen that comes up when creating a new button, which is the equivalent of now having "Style" and "Step 1" open at the same time, stacked vertically:

The new behavior just opens a single tab which could be anything previously selected on a different button, so it could for example open to the "Feedbacks" tab after creating a new button if that one was selected before. This doesn't feel super intuitive for a new button behavior since it's more likely you'd want to program the step actions and a label for the button first. This was the equivalent behavior in previous versions before 5.0.0.

3. Make the first default "Text" element a directly editable box at the top of the sidebar (the "Button text string" part of the element specifically), essentially replicating the previous location and behavior.

I imagine this is the most likely to break things or have edge scenarios where it wouldn't work (like if someone removed all the "Text" elements on a button), so one of the other solutions/workarounds would be better. But this method would directly replicate old behavior where the "Button text string" is immediately available and editable at the top of each button's edit sidebar without having to select any tabs or options.

Usecases

With the most recent stable update (5.0.0+), the method to change a Button's text has significantly changed, requiring more clicks and mouse movements compared to before.

Currently, the steps are:

• Click button
• Mouse move to the style tab and click style
• Mouse move to "Text" element and click text
• Mouse move to "Button text string" text box and click in
• Type button label

The old method was:

• Click button
• Mouse move to "Button text string" text box and click in
• Type button label

The new method adds two mandatory mouse movements onto much more precise areas (both the style tab and the "text" element fields are much smaller than the text string field and require more focus/precision) and two extra clicks every time a button label needs to be changed, which adds up very quickly to lots of extra time and hassle when changing lots of labels several times a day, several days a week. Any UX changes that would reduce the number of clicks and especially precise mouse movements required would be extremely welcomed.

[thedist]

Automatically expand the "Text" element when creating a new button or selecting the "Style" tab of an existing button.

One issue I can see here is that you'd now be adding extra clicks for users who just want to create a button, add an action, then move on to the next button. Not everyone has the use case of needing creating/editing the text of lots of buttons as the primary change.

Move the "Style" tab (or add an option to move) to be physically separated from the "Step", "Feedback", etc. tabs and place it where the "Notes" field currently is (and where it used to be in previous versions).

I'm not sure what you by move the style tab to where the notes section is, because if you look at the style tab there is far too much content for it to work there. The current position of the style tab gives the space needed for all of the element properties to be displayed/edited. If I'm misunderstanding where you would want all of this to be placed then please correct me.

The current behavior (in v5.0.0+) is that the first screen that opens up after creating a new button is whatever tab you were selected on with a different button, which can vary. I understand the rationale for this when switching between existing buttons (changing step behavior, feedback, or style on several buttons in sequence), but it doesn't seem intuitive for new button behavior.

This is one of the things that has had a lot of positive feedback, as Companion remembering the tab it was on speeds up setup for many users.

Make the first default "Text" element a directly editable box at the top of the sidebar (the "Button text string" part of the element specifically), essentially replicating the previous location and behavior.

There's a UX issue with this in that it may be harder for users to understand that it's now possible to have multiple text elements, or how to set the text for anything other than that first text element.

Any UX changes that would reduce the number of clicks and especially precise mouse movements required would be extremely welcomed.

One thing I just want to add for this, if your workflow requires lots of editing the text on buttons have you tried something more dynamic rather than trying to manually go button by button? For example even prior to Companion v5 you would have had to click a button, select the text box, edit text, click next button, repeat. An alternative that's quite common across many productions that require lots of changing of text is to either a) use variables for button text and just edit the variables, or b) use something like the Google Sheets module where you use a cell variable for the button text so that you can just use a Google Sheet to edit lots of cells (button text) very quickly, potentially even automatically or using dropdowns to speed it up significantly.

As for potential ideas for this feature request though, one potential idea off the top of my head is for there to be a button (call it Edit Text or something), that could be positioned next to the Test and Stop buttons, that when clicked could go to the style tab, select the first Text element, and focus the Button Text String field. Subsequent clicks of that button could even cycle through the text elements to speed up editing multiple text elements on a button. This would be non-breaking, the button would be visible regardless of what tab is currently selected, and wouldn't need to change the behaviour of the web ui remembering what tab was last selected.

[tim-sparkstreet]

One issue I can see here is that you'd now be adding extra clicks for users who just want to create a button, add an action, then move on to the next button. Not everyone has the use case of needing creating/editing the text of lots of buttons as the primary change.

I think you misunderstood this suggestion. It's not that the screen should automatically open to the "Style" tab always, it's that when you do intentionally navigate to the "Style" tab it should automatically expand whatever the topmost element is (usually Text).

Right now the extra click for everyone regardless of what they want to edit is to select which element in "Style" they want to modify. I imagine this is the "Text" element the majority of the time anyway, and it's also the default first element in the list.

My suggestion is to automatically select the first element to save a click. If Text isn't what you want to edit you currently have to click on it anyway, it doesn't add any extra work to automatically expand the Text field. No matter what you want to change you currently have to click on something in the elements list because it says "Select an element from the list above to edit its properties" by default. It seems redundant to force a selection of an element when it could expand the first element by default and you can select a different one if you'd like (which you would already have to do).

I'm not sure what you by move the style tab to where the notes section is, because if you look at the style tab there is far too much content for it to work there. The current position of the style tab gives the space needed for all of the element properties to be displayed/edited. If I'm misunderstanding where you would want all of this to be placed then please correct me.

Here's a rough mockup. I think there's plenty of space for it generally speaking but I agree it would take up a pretty significant portion of the screen. Could have a hide/expand toggle that would be functionally similar to having to click on the tab but that partially defeats the purpose of moving it out of the tabs in the first place.

This is one of the things that has had a lot of positive feedback, as Companion remembering the tab it was on speeds up setup for many users.

I agree that this is a great feature when editing buttons, I just personally think that during the creation of a new button the most logical screen to open on is Step 1 to start programming actions rather than possibly opening up on Feedback or something else based on the last edited button.

There's a UX issue with this in that it may be harder for users to understand that it's now possible to have multiple text elements, or how to set the text for anything other than that first text element.

I agree this is the worst option of the three since it causes too many second-order issues. It would be the most direct equivalent to the old workflow but either of the two above options is probably better overall.

One thing I just want to add for this, if your workflow requires lots of editing the text on buttons have you tried something more dynamic rather than trying to manually go button by button? For example even prior to Companion v5 you would have had to click a button, select the text box, edit text, click next button, repeat. An alternative that's quite common across many productions that require lots of changing of text is to either a) use variables for button text and just edit the variables, or b) use something like the Google Sheets module where you use a cell variable for the button text so that you can just use a Google Sheet to edit lots of cells (button text) very quickly, potentially even automatically or using dropdowns to speed it up significantly.

I've done this for things that are very programmatic (like naming buttons for preset numbers in sequence, etc.) and I use the dynamic variables constantly for things like image file names, camera names, etc. but that doesn't cover every use case. A lot of times it would take longer to set up automation than just doing it manually, though now that the manual workflow is twice as many steps that might change!

As for potential ideas for this feature request though, one potential idea off the top of my head is for there to be a button (call it Edit Text or something), that could be positioned next to the Test and Stop buttons, that when clicked could go to the style tab, select the first Text element, and focus the Button Text String field. Subsequent clicks of that button could even cycle through the text elements to speed up editing multiple text elements on a button. This would be non-breaking, the button would be visible regardless of what tab is currently selected, and wouldn't need to change the behaviour of the web ui remembering what tab was last selected.

This would be just fine too but I think adding a whole button that's the equivalent of a simple macro/shortcut isn't really in the spirit of improving the UX, more of a hardcoded workaround. I personally wouldn't mind having such a button but I think trying to fix the clunky flow as the root cause is a more ideal solution. If this is the easiest workaround that wouldn't cause other issues I wouldn't mind it though.

[Julusian]

My suggestion is to automatically select the first element to save a click.

Perhaps instead it should try to match the same element as what you last had selected (ie the 2nd box element, or 1st text element). That would make it easier during normal editing to switch between buttons and make adjustments (same way that we keep the current tab active).
Falling back to the topmost element when unable to match by the other rule.

Chances are that for you that would do the same thing, while also helping the case of clicking through a bunch to edit the background colour or something.

Here's a rough mockup. I think there's plenty of space for it generally speaking but I agree it would take up a pretty significant portion of the screen.

Personally I find that the element properties section already feels too small for the number of properties each element has.
This is why the drawing didnt gain any new abilities from 3.0-4.3, because eating more space all the time in this editor was a hard sell.

I agree that this is a great feature when editing buttons, I just personally think that during the creation of a new button the most logical screen to open on is Step 1

I was about to agree with you, but I would think that the style would make the most sense, so that it can be labelled easily

[tim-sparkstreet]

Perhaps instead it should try to match the same element as what you last had selected (ie the 2nd box element, or 1st text element). That would make it easier during normal editing to switch between buttons and make adjustments (same way that we keep the current tab active). Falling back to the topmost element when unable to match by the other rule.

Yeah, that would be even better.

Personally I find that the element properties section already feels too small for the number of properties each element has. This is why the drawing didnt gain any new abilities from 3.0-4.3, because eating more space all the time in this editor was a hard sell.

I can see this being an issue especially if you add more elements and/or have a smaller monitor resolution. It's not ideal but maybe a scrollable frame with a static size would fix it. Scrollable frames inside a scrollable overall window has its own UX issues though.

Maybe just expanding the last selected element in the Style tab alone is the best middle-ground solution for this without eating up real-estate on the main screen and trying to split the tabs back apart. It halves the added mosue movements/clicks without crowding the pane up with all the extra added features.

I agree that this is a great feature when editing buttons, I just personally think that during the creation of a new button the most logical screen to open on is Step 1

I was about to agree with you, but I would think that the style would make the most sense, so that it can be labelled easily

Well, in the past this was pre-solved because both of them were visible at the same time, ha! Upon thinking about it I agree that style is probably the better default tab over step 1, I was just stuck in the previous mental image where step 1 and style were the same page and it was just the "step" page to me. I do label first before anything so Style is the better default for a new button, you're right.

[Julusian]

OK, I've made it so that it remembers which element type + index within that type was last open so it will remember that when switching between buttons, with a fallback of the first element.
That change will be in v5.0.2 which will be released this week

I'm not sure about changing the default tab when creating a button yet, so leaving that for now. Not something I want to rush into a patch release either, I think 5.1 is a better place for that one to land

[AKmaster1347]

My idea for this is just to have the old text box above or below the notes box that only shows up if there is one text element. the text box at the top can essentially mirror the text input that the singular text element has. If a user has more than one text element its more likely that they wont need a super fast way to edit text and therefore the text box at the top could be hidden, additionally avoiding ambiguity with multiple text elements.

[AKmaster1347]

OK, I've made it so that it remembers which element type + index within that type was last open so it will remember that when switching between buttons, with a fallback of the first element.

Just a note, a possible unintended side effect of this is the tab on another screen switching when the user may not want it to.
Ex: User on screen one clicks "Step 1" causing screen 2 to also move to "Step 1"
This isn't necessarily a bug but it could cause frustration if a user was referencing a feedback while editing a Step

[Julusian]

Just a note, a possible unintended side effect of this is the tab on another screen switching when the user may not want it to.

Not related to this change, but that is unintentional. Thatll be fixed in 5.0.3 at some point