Improving usability for new wait and action groups

[robertskiba]

Hi guys,

as you have suggested in the FB group, I'd like to make a suggestion to make the changes from 3.4x to 3.5 more obvious for the regular user. It's because I don't the a problem for a power user like me, but the regular user (who never reads a fkg manual) will surely have a problem finding the existence of the new wait and action group commands.

So my suggestion would be to place a small button "add wait" and maybe even a button "add action group" to the area in each command where you could find the delay time before.

I suggest that because at least the "wait" command is a fundamental thing to use with companion and many "not-everyday-users" may experience problems if not knowing it. From my view, it would improve usability very much.

[Julusian]

I wouldn't be opposed to adding the wait there (less sure on the action group) to that left panel, mostly because that panel is currently empty space most of the time.
That panel doesn't show for all actions (a few internal ones hide it), and at some point I expect a layout rework will happen which could force removing that button.

But as long as we say we are doing this only when there is the screen space for it, then I am ok with that.

[dnmeid]

I vote against that.

1. The wait and action groups are not more important than other internal actions. Actually having a delay field with every action was giving the delay a much too prominent position. This is now changed and I wouldn't replace one too prominent element with a new too prominent one.
2. If there is a button to add a wait, the next logical question is: why not make a field where you can enter the wait time, so you save one step? Then we're back where we started.
3. One of the benefits of removing the delay field is to free that space for something more useful, i.e. having a better action ui. So we are in a transformation process. If we now add a button the users will complain when we take the button away.
4. A button within an action area to add another action above is completely unituitive and we don't use that workflow anywhere else
5. You say that you, as a power-user, don't have a problem with it. I say, that if the not power-user manages to find "change button background" action, he will also be able to find a wait action and we don't hear any complains that any of the internal actions is too hidden

I think what you are experiencing in the moment is just a discomfort because something has changed that you are adopted to. Get over it.

[Julusian]

I would counter by arguing that users expect to find delay there, so will be confused when they don't find it. Adding it as a temporary transitional assist might be beneficial.

If I try to get into the mindset of a user who doesn't know this change is coming;
As actions have always had a delay, where is the logical place to think that would have moved to? Is the most obvious answer that it is now itself an action? These users aren't aware of the new action group, so to them all the actions execute at once, in roughly the order they are placed (but not guaranteed to match), unless this delay field is set.
So if missing the knowledge about the changes to execution order, having a delay action would be stupid, what would that accomplish?
Maybe I have to enable a setting somewhere to bring this field back?
Was it removed for some reason?
Maybe this is a bug and it will reappear in 3.5.1 once someone realises?
Lets install the version I last used as I know that could do this.

So my hope would be that by having a short-lived button here, users will be able to easily stumble upon this themselves. Then when we eventually want the space for something else, we can remove it and rely on users having realised that it is just an action (because they have seen the action now), and will think to add is as an action.

Besides, in 3.5 that area is just empty space now. Maybe it will remain that way until 3.23, making this button be not so short-lived.

And yes, this won't help every user, but it gives a smoother path for discovery for a reasonable chunk of users and hopefully avoid an influx of 'where did this go?' questions/frustration soon after the release of 3.5

[robertskiba]

I completely understand Dorians perspective, but I was just nearly laughing when Julian described what I experienced (I call myself a Companion poweruser):
I first thought it was a bug, tried to install an older beta from some days ago... Then I was looking for a new option in the settings, but didn't find some.
And I don't want to know what people who were already overwhelmed with the change from v2 to v3 (Steps instead of latches) may experience.
Please keep always in mind that the perspective from the field is another one than if you are a developer.

My suggestion would be to add some intuitive button, maybe with a combined clock and "+" symbol. Add it at the same position where everybody is looking for the delay times. If it stays forever, may be removed someday or even gets an additional button next to it that would make sense? Let's see!

Greetings
Robert

[thedist]

In my mind some of the issues raised here are indicative not that we need to put a feature in the face of every single user regardless of if they actually need it or not (ie, showing a button on every action that would add a wait when clicked), but rather an educational issue where we're not getting information of changes to users in a way that's clear and concise.

One thing I would like to see is the implementation of notification icons, perhaps in different areas of the Web UI (such as a notification bell in the top corner for important Companion notifications, in the edit button or actions panel there could be another notification icon), and these icons could act as a Call To Action to indicate to the user 'Hey, something new here, read me!' that when clicked would open a modal with all the details relating to what has changed. This would help all users, both those using beta versions who don't know how to read commits to see changes, and those who will experience changes when new Stable releases happen. Additionally such a CTA wouldn't be limited to action groups/delay info, it could be used at any point to indicate new features, changes, link to the section in the Getting Started Guide etc...

There could even be an option that's enabled by default to open a modal window on the first load of a new version with a list of changes, that when dismissed would still be accessible through the notification bell icon.

I think getting information to the end users is better than changing the UI or adding elements in different ways and hoping the users figure it out.

[Julusian]

I think that would be good, but is probably a slightly longer term thing. I don't see this happening within the next week in time for 3.5
So I am tempted to still add that 'add wait' button for 3.5, with the aim of something better for the next version.

There could even be an option that's enabled by default to open a modal window on the first load of a new version with a list of changes, that when dismissed would still be accessible through the notification bell icon.

I did start thinking the other week about whether we should start with some longer-form changelogs (more along the lines of https://code.visualstudio.com/updates/v1_96), but don't know where to put these. The modal you propose would be the perfect place for them, as well as perhaps inside the getting-started docs (which would also make them available on the website)

---

My big worry with this is whether it will be updated/utilised fully. I often forget to update the docs for new/changed things and I'm sure others do too. And for some changes, I think there could be a question of whether it should be included in these notifications, or if it is too minor/niche for that.

I think it will also be hard to find a balance of not showing unnecessary notifications to users too often but showing them enough.
For example, I may be using 3.3 one week, then the next week I use 3.5 but on a different machine. Should I be shown these notifications? How many versions back will they show?
The next week I use 3.5 on a different machine again, now I don't need/want those notifications.
I expect this is a pretty likely workflow, so should be catered to.

[robertskiba]

I think it's a very good idea to implement some more information on places where users of the older versions may look for something. An ( i ) symbol showing information when hoovering over it (“Where did the delay option go?”) would already help. This would still even be a good thing to help some users with the steps replacing the latches. Me, personally, I'm a big fan of the steps, because it was a very wise decision to implement them as it gives much more flexibility than the v2.x system, but there are so many users (in my line of work) who told me they were afraid of updating to 3.x because of the latches were suddenly gone. I explain to them the steps, and then they are completely happy, but no one explained to them before (and the just never read the manual because of lazyness or no time for it!!).

[robertskiba]

I just tried to put myself into the view of a person that's not trying to use beta versions or not reading any changelogs of companion.

This is a screenshot made with a resolution like that of an old bad laptop at 1440x900 (and let's suppose that would be the worst case resolution anybody may use in production)

There would be enough space without interfering with other elements to add two buttons either above the "+ add key" element (where the old delay element was located) or to the left oft the "+ add key" element.

The buttons could be same size and style as the red folder button on the right side.

Button 1: Time/Clock symbol with a "+", hovering the text "Add wait time" or "Add wait/delay element" or similar to add a wait command.

Button 2: Some adequate symbol with a "+" to add an action group and hovering "Add action group". If you click it, you maybe asked if you want the execution mode "inherit", "concurrent" or "sequential", maybe even with a short description.

[dnmeid]

I totally agree with Jeff that with a better way of notification we could reduce the confusion of some users about changes.
We have the wizard for first runs, maybe a simple and fast to implement solution could be to have a "what's changed" popup, that opens on startup. You can close it or dismiss for the time you use this exact version.

I also agree that the empty space where the delays used to be can easily lead to the assumption that this could be a bug or new option to bring them back. So I feel we should use that space right now. We've been discussing somwhere else that layout of the option names left and inputs right. Given that this layout change is not a big task we should do this already for 3.5. I think this will avoid having to do this very discussion with a lot more users.

And of course my opinion still is that a temporary button in that space will do more harm than it helps. You're always trying to help the users that are to lazy to catch up with changes in a software they rely on. All new users that open Companion for the first time will think we are completele crazy.
I know that even today there are still users that ask where the toggle has gone. So what. They get their answer by friends or in the user forum or in the documentation if they would read. Maybe they'll stay on 2.4 forever. It's not that I want to piss off those lazy adopters on purpose but I think we should not sacrifice a consistent and improving UI just to please their lazyness. Also we cannot expect that Companion can grow on features and stay exactly like it is. It always seems easy to just add a button or a checkbox or an info. You think you're not taking anything away by just adding something, but actually you're taking away cleanliness, overview, focus, sometimes consistency.

[Julusian]

Removing this 'empty space' will need a little thought, as it is still used for some things, but those things are not always shown.
I'm not sure its as simple as just moving them, as that will blur the lines between which things belong to companion and which belong to the action/feedback, especially as the 'connection' field is also new

to have a "what's changed" popup

As I said above, I am fine with this, but unless someone is volunteering to do this I suspect this won't be done in the next week in time for 3.5. If that is the case, are you fine with leaving users in the dark again? Is that the preferred option instead of a temporary button that can benefit on muscle memory.

You're always trying to help the users that are to lazy to catch up with changes in a software they rely on.

In a way I agree, but we don't make it all that easy. We do write a changelog, but that is often a bit cryptic. If we start having longer form changelogs though, then that should make it both easier and clearer

[dnmeid]

I think for the user it is not so important if an input is originating from Companion or from the module. More important is a logical order. I tend to say:

1. Info text (full width)
2. Button Preview
3. Connection selection
4. Invert
5. Module options
6. Boolean feedback options

It seems that all of this is optional.
I think the learn button should be in the same line as the option name and the input. Maybe we do the names left aligned in a column and the the small info icons and learn right aligned in the same column.

I guess most actions will be a little shorter then and most feedbacks a little longer. But I expect an overall improvement of the layout and we could reduce the overall width of the action/feedback editor

are you fine with leaving users in the dark again? Is that the preferred option instead of a temporary button that can benefit on muscle memory.

I think that is an exaggerated formulation. I don't want to leave users in the dark, but I don't want to introduce a bad UI just to point out a change. If we need to communicate a change we should communicate it in the best possible way and not in the worst.

I suspect this won't be done in the next week in time for 3.5.

If this means we are not ready yet for releasing 3.5 then I'd rather accept that. For me the alternative would be to hold back the changes in question and not release them with 3.5 instead of releasing a change that appears to need a hack to be figured out.

[Julusian]

I think for the user it is not so important if an input is originating from Companion or from the module.

I guess so, but I think that the invert field could be problematic/confusing. That is something we add to every boolean feedback unless either the module opts out of it, or we detect a field that appears to be an invert option.
For example, maybe the feedback has a single checkbox 'is on air' and companion then also adds an 'invert' checkbox.
I think this makes us more completele crazy as an 'add delay' button would.

I would also be tempted to not move the button preview, as that would eat quite a bit of vertical space and is guaranteed to be pretty narrow. Maybe it could be responsive and move to be a row on narrower screens.

I am also wondering if this will make the boolean feedback options to be rather messy. each style field under the feedback would need to become its own line too, which will over double the vertical space it occupies in most cases. It is quite compact at the moment containing at times 3 input fields (plus the field selector) on one row

This uncertainty/potential confusion makes me nervous about changing this without it having some time to get some testing by beta users.

If we need to communicate a change we should communicate it in the best possible way and not in the worst.

Doing nothing is the worst option, with the temporary button being a middleground. The full fancy ui modal would be the best, but I am unsure on the timescale of that. So if we can't do that, I would rather the button than nothing.

If this means we are not ready yet for releasing 3.5 then I'd rather accept that. For me the alternative would be to hold back the changes in question and not release them with 3.5 instead of releasing a change that appears to need a hack to be figured out.

I don't think holding back these changes from 3.5 is viable, doing so would break the config of those currently using the betas

I don't mind holding back the release, as long as we know roughly how long it will be for. I'm afraid of ending up in the situation where the release is blocked on something that isnt being working on, so it gets held off for months until it gets shipped anyway.
While we don't explicitly have a public release schedule, the issue milestone has had a date of January on it since 3.4, and when anyone asks about 3.5 they have been told to expect it around january. It won't be great to go from having a rough timeline to change to saying 'when it is ready' not knowing when that might be.

So I am still very tempted to take the quick route and add the button for 3.5, and then immediately remove it in develop and do the proposed rearrangement. I don't mind having something a bit rough temporarily, that is how ui things I add often end up until someone does some polish

[Julusian]

I took at look at rearranging this panel yesterday, and I think I have it mostly working in develop. I didn't rearrange the style field for boolean feedbacks, simply because the component is shared with the main style fields and will be annoying to make work for both (or it could be duplicated so there is one for each)

I'm not confident enough to want to pull it into main though, it is quite likely that I broke something somewhere digging around the css like I did. And because of #3185 it won't be a clean cherry-pick.

Some screenshots from a windows at ~1440px wide:

[dnmeid]

Even if this may get some more tweeks, I immediately feel this to be an improvement. Definitely worth having it in 3.5

[Julusian]

I found time to do this 'whats new' modal the other day. I filled in a tab for both 3.5 and 3.4, I think it would be nice to keep older versions there for those who haven't updated in a while. Maybe latest I will fill in further back too, but this is far enough for now.

So I think this is done as much as we need to for 3.5. In 3.6 the rearranging the ui will land, and if anyone want to do anything or has ideas on what needs polish, other bits could be improved too

[dnmeid]

Julian, you're the man! At what occasion will this open?

[Julusian]

I think I made this track whether it had been shown via localStorage, so will open when first opening the ui for each browser. This is maybe a bit too agressive, but its a single click to dismiss it so am curious if anyone will complain.
It tracks what the last showed version was, so when we add a 3.6 page to the docs it will show again.

I should also add that this modal is technically showing pages from the getting-started docs, so this content is also visible at the bottom of that both inside companion and on github.

And the content was based on the changelog, anything not expanded upon is pasted in its original form at the bottom https://github.com/bitfocus/companion/blob/main/docs/9_whatsnew/v3-5-0.md