Improving workflow for recording

[jkhartshorne]

Our testers are finding the current workflow for recording to be very confusing. Below I've mocked up a different flow. The first page is the same but with the wording simplified. Each button will have an icon, TBD. From there, you go to the appropriate recording / upload page, which isn't changed either:

From recording, the first stop is a new page with two options: "save" or "crop first". This addresses concerns we (and users) had raised. If they choose "crop first", they go to the current "crop & save page", with some minor changes. Most notably, the "clear conversation" option is gone (this will be explained shortly). If they click "save", they get the same page but with the cropping function gone:

Either way, the next step is the same: a page asking them whether they want to make a snippet or return to the main menu. What happens next is pretty obvious. The snippeting page should look similar to what was in the wireframes.

Note that I want the term "snippet" instead of "clip" everywhere. I never liked "clip" but agreed to it because it was going in the menu and "snippet" was too long. But now that it's not in the menu anyway, I prefer "snippet".

[jkhartshorne]

@alexchippendale Please let me know if you have any questions, or if you anticipate significant difficulties in doing this. It's possible I can think of something simpler. But even though this involves more pages, I think ultimately it'll make for a much smoother experience for users.

[jkhartshorne]

PS I'd tag Lorena, but she's not on this repo yet.

[alexchippendale]

@jkhartshorne That makes sense to me. I don't anticipate significant difficulties in doing this other than a little bit of extra time to build and test (but I don't think anything too crazy). Also, I'll add Lorena to this repo

[jkhartshorne]

@alexchippendale @lorenachipstudio @SecondStreetDevelopment

So audio processing takes too damn long. As a user, it's super frustrating. You can probably speed it up, but unless you can get it to under 10 seconds (preferably under 5), we'll have people closing their phone, exiting the app, etc. -- all of which probably causes it's own problems (I'm guessing?).

You used to do processing asynchronously, but that caused problems with cropping, etc. So ... let's just wait on cropping and extracting snippets.

Here is a new workflow in which you record, and processing starts immediately in the background. You have the option to do some labeling now or just return to the main menu. If you do the labeling, then on completion, you go to the main menu. So no matter what, you don't crop or extract snippets now.

P1.pdf P2.pdf

But this raises a separate problem: how do people know when their recording is ready for further processing? A notification list!

1. Add to the menu a "notifications" list. The icon is straightforward: just a blue circle with the number of unread notifications.

2. Also add the notification circle (with number) to the main page in the top-right corner (or somewhere).

3. Clicking on either takes you to a notifications page, which is just a list. For instance "Conversation #X ready for editing". (I assume you have an ID for each conversation in the database, so that provides a number you can use." <--- I don't care about the number, but we need some way of distinguishing a long list of "Conversation ready for editing" notifications from one another.

Click/tap on the notification to be taken to that conversation so you can edit it. (Obviously, you have to be able to crop, clip, tag, label, etc., from the scrapbook. But most of that is already on the todos.)

Or swipe left to delete the notification.

---

Our thought is that this should allow for the cropping, tagging, etc., to be unobtrusive. You can do it if you want. If you are in a hurry, you can do it later. Or you can do it never. Up to you as the user. We prefer people clip & tag, but we'd rather have some data than none.

My hope is that this would simplify the programming as well. It matters less just how long processing takes, and it can happen in the background.

ASSUMING that closing the browser/app prior to finishing processing isn't problematic. If it is ... then we are in a different ballgame and need to a) speed things up, and b) convince people not to close the browser/app.

[SecondStreetDevelopment]

Hey @jkhartshorne, I hear you on the processing taking too long issue. I was just brainstorming some possible solutions to this in relation to the recording UI/workflow yesterday. I'm not real familiar with this part of the codebase yet so my ideas may be way off...I'll get with @alexchippendale and see what might be possible.

[alexchippendale]

@jkhartshorne We are currently building this new flow, and are aiming to get it out later this week on staging. We are also aiming to get additional editing options for scrapbook tiles out, and potentially some other items from this repo onto staging this week once they are completed. We will update you when they are done and ready to be tested.

[jkhartshorne]

Great. Looking forward to it.

[alexchippendale]

@jkhartshorne Part of this new flow has been deployed to staging, which should reduce waiting times in app. While still in development, we've removed several of the extra steps and loaders when submitting a live or uploaded clip / snippet. When you submit something new, you'll be able to record again right away, and you'll receive a notification when it's fully processed rather than waiting on a loader:

We are continuing to work on this, which will include clipping options and the ability to make snippets from conversations. These will happen from links / buttons in the scrapbook tiles that will take you to those sections once items #1 and #2 are complete, so people aren't spending time waiting for processing in the recording section. We'll also add symbols to the record buttons, and adjust the process to follow more of what you've included above.

[jkhartshorne]

So the new processing has been working quite well for us. You can see that from our timing tests, here:

https://docs.google.com/spreadsheets/d/1VBkhsQzyk5brgE5gXdnmh7aMFtC3ZFoy_-6l7HYDhJg/edit#gid=0

Part of that is the fact that we no longer wait for the second part of processing. But part of it is that it does really just seem to be a lot faster. Thanks!

[alexchippendale]

@jkhartshorne Excellent to hear! We've been working hard to get the wait times and feel of the recording flow faster.

The recording flow seems to be in pretty good shape now. We will update the copy / remove buttons or text that don't belong as described in the other tickets. Other than that, is there anything else for this recording flow that needs to get out for the phase 2 launch on production? We can always make updates after as well, but I wanted to make sure that we're not missing anything important. We are looking to deploy to production later this week.

[jkhartshorne]

Nothing else big-ticket. Except of course making sure we have as many bugs squashed as possible.

On Mon, Aug 31, 2020 at 7:47 PM alexchippendale notifications@github.com wrote:

@jkhartshorne https://github.com/jkhartshorne Excellent to hear! We've been working hard to get the wait times and feel of the recording flow faster.

The recording flow seems to be in pretty good shape now. We will update the copy / remove buttons or text that don't belong as described in the other tickets. Other than that, is there anything else for this recording flow that needs to get out for the phase 2 launch on production? We can always make updates after as well, but I wanted to make sure that we're not missing anything important. We are looking to deploy to production later this week.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/alexchippendale/KidTalkRemainingTasks/issues/19#issuecomment-684105926, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABOVVY5TPJ5YOOTKPVEGXZTSDQY73ANCNFSM4P2ENOJQ .

[alexchippendale]

Sounds good.