improve ui user experiment

[dddeveloperrr]

Hello I wanted to suggest an improvement for UI Design. The "start recording" button at the top is kind of confusing. It would be much much better to bring it down to the bottom so that all the buttons on the page are kept alongside each other. personally, every time I want to record a video, I unconsciously click on "save recording" button at the bottom ( instead of clicking start recording at the top). It would be so nice if a toggle button added at the bottom for both recording and pausing of video ( and also an image for pause and record next to button caption) please look at this image:

[sidorsett]

Hi,

I support the proposal to move the "Start/Stop recording" button to the bottom, but would go even further:

• What is the "Save recording" but for? Why not to save every recording automatically? If I, as a user, want to delete the last or any other unnecessary recording, I can always do it with my favorite file manager (and to facilitate it, you can add a button that opens the folder specified in the "Save as" input in the external file manager).
• What is the "Cancel recording" button for? As above, it is enough just to automatically save the recording, when the recording is stopped. The user can delete anything in the file manager.
• Why do you need "Back" and "Continue" buttons on the other pages? The buttons assume a wizard-like configuration. But SSR doesn't need a wizard. I would propose to add tabs at the top, so that the user could easily switch between sets of the settings. And to leave only "Start/Stop recording" button on the bottom, which stays visible and available on all tabs: you can start/stop recording independent of where you are now. There is no use case with missing configuration options that would prevent the user from doing the recording.

Cheers!

[MaartenBaert]

The wizard-like UI made sense for earlier versions of SSR where you actually had to go through the options at least to configure a file name, and the UI did validation of your settings whenever you pressed 'continue'. That changed when the system tray was added and people wanted options to start/stop the recording at any point. This forced me to add a default file name and change the validation logic. So admittedly the current UI is a bit strange now.

Still, there is one thing SSR currently can't handle, and that is changing settings while a recording is in progress. This isn't obvious, but when you go to the recording page, it triggers a number of things, like processing all the settings from the previous pages, starting the JACK backend (if enabled), launching the OpenGL application (if enabled), opening the sound device for notification (if enabled), starting the inputs for the preview (if enabled), running the recording schedule (if enabled), and more. Some of this can in theory be postponed until the recording is actually started, but this has some downsides, in particular it would cause SSR to take more time to respond to the 'start recording' command.

This is not a new idea, people have suggested the same thing years ago and I have thought about this, but I don't really see a clean solution that's substantially better than what I have now. I don't really feel like making significant UI changes unless there is a significant benefit. In general people prefer whatever UI they are already familiar with, and every change adds confusion.

Edit: Regarding the whole start/pause/save/cancel situation, this originates from the earliest versions of SSR where I wanted to have only one global hotkey to start/pause the recording, so the user doesn't have to remember multiple hotkeys while they are e.g. playing a game. Originally there was no 'separate file per segment' option so the 'pause' button actually did pause the recording and 'save' actually did the saving. Now it's a bit more complicated. It seems that this still confuses people, so maybe it would be better to drop 'separate file per segment' and switch to actual start/pause/save/cancel buttons. But then I don't really know what to do with the hotkey. Having separate hotkeys for each button sounds very annoying.

And yes, people do use the cancel button. It's very convenient when recording presentations or tutorials in multiple short takes since it provides an easy way to delete bad takes.

[sidorsett]

Hello, Maarten.

If you want to exclude reconfiguration during an active recording, then what do you think about the different solution. You can keep only record-related buttons in the main window and hide all configuration options into a modal window opened through the "Settings" button. The "Settings" button would become inactive (grayed-out) during an on-going recording. Moreover, you could remove the main window completely and leave only menu options in the system tray: start, stop, cancel, settings, about...

My primary concern about the current design is that I am very afraid of losing my work (i.e. the recording). To ensure that the recording got saved, I have to stop the recording and to explicitly save it. Don't you think, it would be much more safer to save the file on the fly? If you say, your users want to have an easily accessible option to remove the file, you can keep the "cancel" button that stops the recording and removes the file, but otherwise, the file should get saved independent of whether the computer got shut down in some reason during the recording, the application crashed, the storage got full or the user forgot to save the recording.

Cheers!

[MaartenBaert]

The 'cancel' button already shows a warning, it's very hard to accidentally stop the recording without saving. Also, changing the UI really does not change whether the file is saved 'on the fly' or not, this is always the case. You just need to pick a file format that doesn't become corrupted when the recording is interrupted (i.e. use MKV instead of MP4).