Suggested modification: Play video button moved into a popup dialog

[farazs]

Right now, in the main recording screen, there's two buttons: "Prepare to Record", and "Auto Record". After a recording is made, a third button is added to play the video. This seems like an odd flow to me since there are no circumstances under which this button goes away. Also, if the user deletes the file for some reason, the button persists and gives an error when clicked.

An alternative to this could be a dialog that pops up when a recording is finished that says "Recording finished!" and has two buttons: "Play Video" and "Close"/"Okay"/"Dismiss". That way if the user does not want to play this recording, and wants to record other things, the button has a lifetime. It is also clear which recording this button is going to play since it appears right after you finish recording. I suppose a user could still delete the file while the dialog is open and click the play video button, but this seems far less likely, because the user would probably close the dialog right away if they didn't want to play the video.

Here's the mockup: https://docs.google.com/drawings/d/11gbqhmDQKJDOMrE4zZ3RUnsmM1ZlvtzwdC8MVaGuYZg/edit?usp=sharing

[zxiiro]

To be honest, I don't like this workflow because this adds an additional button click / step after a recording is over to move on to the next recording.

In the field when we are doing lots of recordings it's not often that we watch a video. Typically we view the first few video recordings to make sure the gear is properly setup and once it is setup usually the remaining videos are okay.

From a design and end user point of view I also find popup dialog boxes irritating, when's the last time you saw a popup dialog and thought "thank god that's here"?

Popup dialogs should be used sparingly in my opinion.

[farazs]

Hmm.. how using the status bar at the bottom of Freeseer instead? When a recording stops, it says "Recording completed" in the status bar, and if you press the "Play Video" button and the video is not found, it would show "Video not found." in the status bar instead of having an error window popup with the awful error sound (on Windows).

A problem with this might be that the status bar may not be something a typical user looks at or notices, and so they might not understand why the video is not playing.

[zxiiro]

Last term a student was working on fixing #153 regarding adding a notification system that would improve sending the end user notification details but the project was not completed satisfactorily. You could potentially look into this if you are interested.

The previous PR for this project was #479.

[dideler]

I also don't think a popup improves the workflow. On the other hand, I do find a new button sneakily appearing to also be a UX blunder. Yet we don't want to have too many buttons on the recording UI to keep it simple (but minimalist does not always mean simple).

@farazs feel free to offer more suggestions here, but in the meantime I'm closing this issue.

[farazs]

How about just having a "Prepare to Record" button which changes to a "Leave Recording Mode" button when it's pressed. This issue this would address, is that right now there's no way to go back and change the talk you have selected, after you have pressed "Prepare to Record" (unless I just haven't found it?).

And there could be a bar with Record, Play, Stop, buttons (either with text or with the conventional icons for those buttons). Alternatively you could have just Record, and Play buttons with the Record changing to Stop as it does now. The play button could be there from the start and be greyed out and unselectable instead of appearing when it's usable.

[zxiiro]

The purpose of the prepare to record button is it sets up a GStreamer pipeline in the backend to be ready for recording. That way when you press "Record" there is no delay in the recording from when the user presses "Record" to when the recording actually starts.

I agree this is kind of a hack but there's no easy way to solve this problem with the way Freeseer's backend is currently designed.

Either we jump right into recording and have a delayed start, or we have a ready state in between as we do now so that when you really start the recording starts immediately. Either way pressing "Prepare to Record" is like committing to the recording and that you've already started the recording (file is created at this point) so to get back to selecting a talk you have to stop the recording first).

[farazs]

Well if you had a "Leave Recording Mode" button, it could just delete the recording file right? In essence, if the user leaves recording mode without starting the actual recording he probably doesn't want to keep the empty file. In terms of the underlying system, the recording has started, but from the user's point of view it hasn't. So the UI should respond in a way that follows the users understanding of what's going on, and abstract away the underlying details?

[zxiiro]

How would you determine if the file had no recording vs if there was some recording started?

How would the button placements look in practice? Can you make some quick mockups that show state of the buttons?

[farazs]

So when "Prepare to Record" is pressed, you have a variable that you set to false. If the user hits record after this, then set that variable to true, and we know that there's recorded content. If the user hits "Leave Recording Mode" then only delete the file if the variable is false.

Alright i'll work on mock ups for this

[zxiiro]

Couldn't you check the file size of the file to determine if there is useful data in the recorded file?

One feature of Freeseer's recording system is that if you stopped a recording (maybe technical difficulties) and restarted recording the same talk, Freeseer would automatically suffix a number at the end of the recorded file so that you don't lose the previous recordings, it will also increment this number many times if there are more starts/stops of the recordings, we can then later use these files to concatenate back into one big file again.

How will your feature handle this case?

[farazs]

Yeah I suppose you could check the file size to determine whether there is useful data. Though you would have to hardcode what the initial file size is when nothing has been recorded. I'm not sure if there is some metadata that is put into the file when it is first created. This metadata may also vary depending on what format you are outputting.

A solution that wouldn't have to deal with this, is to have a "isRecorded" or "hasContent" variable in the talk itself that keeps track of whether this talk has been recorded before and not delete the file if it has. I'm not sure if something like this variable exists, or if the counter you mentioned could be used for this purpose.

[zxiiro]

Have you tried checking the file it creates initially to see what the file size is across a few attempts?

I suspect they would be fairly similar... and then you could make an educated guesstimate on what is considered a useless recording like a 0.5 second recording and assume it should be deleted. Just a thought.

[zxiiro]

@farazs in case it wasn't clear I was only asking for quick mockups, eg a quick drawing of the proposed button placements or a very quick demonstration of what they look like, should take no more than 10 minutes of your time.

Last term one of our students used some sketching software which I'm not familiar with maybe one of the other mentors know. You can see an example from #411.

One trick I often use myself is to use Qt Designer to drag and drop my widgets into place and take a screenshot of the placements to post when I want to share with others what my vision for something is.

Qt Designer: http://qt-project.org/doc/qt-4.8/designer-manual.html

Hope this helps.

[farazs]

Sorry, yeah I understood that it was a quick task. I was trying to set up a virtual linux environment for Freeseer since the Windows version of gstreamer that's in the quick-start guide doesn't have the plugins for streaming. Freeseer wasn't working on my virtual linux environment so I was trying to sort that out and then travelling after the sprint ended.

In terms of guesstimation for the file size: I am worried that if I select a particular value based on the initial file sizes that I observe with all the various output formats, somewhere down the line this could cause problems (for eg. if Freeseer starts supporting another file format that has a larger initial file size). An approach that uses user-input and talk information stored by Freeseer to determine whether a recording has useful content would not be affected by this.

In the mock ups I have text-based buttons for Record, Play and Pause but these could also be icon-based or have both icons and text. The idea is that the buttons are always there but get greyed out depending on the actions the user has performed. When nothing has been recorded and the user has not clicked "Prepare to Record", they are all greyed out. Once the user enters record mode, recording becomes available. Once the user starts recording, pausing is available. After the user is done recording, playing is available. So there's no suddenly appearing buttons. Also, the "Prepare to Record" button is replaced with a "Leave Record Mode" button that would allow them to go edit the talk information (and either delete the empty video output file or keep it if it's non-empty).

Here are the google drawing links if you want to make modifications or suggestions on the drawings themselves : https://docs.google.com/drawings/d/18G03c7RliUQMY00hXA4HO55W5TZQEkqMWVhXD-gPF6w/edit https://docs.google.com/drawings/d/1DB5594kg1qb6Oejct9lxVISBmpCQ43fZam6mFx0EI0E/edit

[dideler]

The UI suggestions are worth exploring IMO, but we won't know how they perform compared to the current UI until we can try them both (ideally we'd do user testing, but we don't have the resources for that). This means that your work could be scrapped if it turns out that it's not superior from a usability standpoint to the current workflow. Would you be okay with that?

I'm also interesting in hearing what others think.

[farazs]

Yeah I'd be okay with that. If everyone thinks the UI suggestions are worth exploring but when the result is tested for some reason the old UI is superior. As long as I get credit for the work if the problem with the changes is not because of poor implementation.

[dideler]

As long as I get credit for the work if the problem with the changes is not because of poor implementation.

From the course's perspective, you'd be fine as long as you made steady weekly progress and communicated. You wouldn't get a lower grade if we reject the UI. A project with a failed outcome can still be a successful project.

[farazs]

If I'm going to be implementing this, should I edit the issue so that it matches the later UI suggestions or open up a separate issue entirely?

[dideler]

Open a new issue and include a reference to this one from the description.