Frontend: change "Clean output" button label to "Remove output"

[pohlarized]

Closes #29

I was lazy and only changed the label, the underlying function and id are still using the "clean output" term.
Unsure how important it is for you to keep that consistent.

[MayNiklas]

There is one thing I'm unsure about:
"remove output" could imply, that the result is getting deleted from the server 🤔
What do you think? Is that naming misleading? "Hide output" could be a valid alternative.

For clarification: the backend stores the result as Python objects in memory - nothing is written to the disk. We do garbage collection every few hours. There is currently no API endpoint to manually trigger a "DELETE".

[pohlarized]

Yeah i agree, "remove" might also be misleading if you have the backend in mind.

Regarding that I am not sure if it is really an issue even if the user's perception is incorrect?
As in, since we have cleanup every few hours, are there scenarios where we believe that it really is an issue that the user believes the backend has deleted the transcript forever, but it is still there (and still fetchable if you have access to the service and know the ID)?
If we have reason to believe that these scenarios can realistically exist, then sure, we might want to come up with a different name.

I agree that "hide" would capture that it is still available on the backend.
Though especially because that is the implication, i would expect that there is a way to "unhide" my transcript again, i.e. another button or something that fetches the transcript again.

I have not been digging into the service enough to know whether that is easy to implement, or whether we might run into issues since you can e.g. have multiple active jobs on the same page.

[pohlarized]

I have not looked at this too much in the source code but just tried it out, but i feel like the button doesn't just hide the output, but it essentially resets the page to the state you get when you initially load it.
So perhaps something like "Reset" would work?
And to indicate that it's a "dangerous" operation make it red / orange / yellow instead of green as well?

[MayNiklas]

I agree that "hide" would capture that it is still available on the backend. Though especially because that is the implication, i would expect that there is a way to "unhide" my transcript again, i.e. another button or something that fetches the transcript again.

I have not been digging into the service enough to know whether that is easy to implement, or whether we might run into issues since you can e.g. have multiple active jobs on the same page.

While the backend of this application is very very well done, the frontend was meant as a placeholder / to be simple - I mostly use the API myself 😅
It consists of 3 files: index.html, script.js and style.css.
-> On upload, a Post request is sent against the backend
-> Once per second, the browser sends a request to the status route to check, if the status of the job changed
It's super minimal and simple. No framework or any modern tooling lol.

The "clean" action literally just deletes the output from a local variable.

[MayNiklas]

I have not looked at this too much in the source code but just tried it out, but i feel like the button doesn't just hide the output, but it essentially resets the page to the state you get when you initially load it. So perhaps something like "Reset" would work? And to indicate that it's a "dangerous" operation make it red / orange / yellow instead of green as well?

Thats correct. Reset would be a good idea.
In the long term, I could store the history of UUID's in the browser storage -> clicking on them could refetch the result.

Will implement that soon 👍

Did you already use the API?

[pohlarized]

Thats correct. Reset would be a good idea. In the long term, I could store the history of UUID's in the browser storage -> clicking on them could refetch the result.

Will implement that soon 👍

Sounds good, thank you! Sorry for abusing the PR for discussion now instead of the issue, i thought maybe it would be a good quickfix 😄

Did you already use the API?

I mainly use the frontend, I have only used the API to debug some problems I had using the frontend, but i didn't use it to actually perform any work.

[MayNiklas]

@pohlarized the API has a interactive doc...
-> /docs

Depending on what you want to achieve, you can use a very simple shell / python script to:

1. upload all the tasks
2. get the results once they are done

This might be very helpful if you have a folder with n audio files and want a txt file for each of them.

The API is super simple and very helpful if you want to avoid manually having to upload each file / save the result.
Take a look at it ;)

[pohlarized]

I will take a look, thanks.

[nonchris]

In the long term, I could store the history of UUID's in the browser storage -> clicking on them could refetch the result.

they're garbage collected after a specified time, see the env variable DELETE_RESULTS_AFTER_M

Time after which results are deleted from internal storage (default 60)

i personally think that an "extended" history or something would go against our principle of privacy first.
and a restart of the app would kill the full history anyways, since we don't store anything persistently...

Maybe the front-end could save previous results n the local storage? the same way better-gpt and other tools do/did...?

lastly.: I like the idea of a real "clear" endpoint in the API, so that you can ensure that the data is wiped as soon as you're done.

[pohlarized]

they're garbage collected after a specified time, see the env variable DELETE_RESULTS_AFTER_M

Time after which results are deleted from internal storage (default 60)

This could be exposed to the frontend though, so that the frontend can store the time of expiration for a given record and then simply disables the button to re-fetch results.
And even if the frontend was unaware (because the deletion happened for another, non-timeout reason), you can always gracefully handle a 404 by the API in the frontend and display a meaningful error to the user.
But of course, going by niklas' earlier description, that would probably increase the size and complexity of the current frontend quite a bit.

i personally think that an "extended" history or something would go against our principle of privacy first. and a restart of the app would kill the full history anyways, since we don't store anything persistently...

Maybe the front-end could save previous results n the local storage? the same way better-gpt and other tools do/did...?

Not sure what you have in mind when you say "extended" history.
But I agree that it should always be transparent to the user how long certain data is stored where, given the context that the transcription service might be used in and the potential sensitivity of the data.

lastly.: I like the idea of a real "clear" endpoint in the API, so that you can ensure that the data is wiped as soon as you're done.

Sure, that sounds good.

[nonchris]

and even if the frontend was unaware (because the deletion happened for another, non-timeout reason), you can always gracefully handle a 404

Assuming we'd have that list - where is the real benefit it's basically a collection of "dead links" because everything was already GCed?

Maybe a "whopsie, go back to the last transcript" button would be a simpler approach?
it would also only be one additional uuid the front-end would need to store. and the chance of it still being available is much higher.

Not sure what you have in mind when you say "extended" history.

idk why i said extended tbh. i just meant a type of history that has like... idk the last two weeks or even all the transcripts ever created available.
so "extended" meant "for a longer time" or something like that.

But I agree that it should always be transparent to the user how long certain data is stored where

Also a good and simple addition to our frontend. why dont we simply display a message "your transcripts will be available for X minutes" @MayNiklas?
(the answer is probably bc we didnt think about it before)

[pohlarized]

and even if the frontend was unaware (because the deletion happened for another, non-timeout reason), you can always gracefully handle a 404

Assuming we'd have that list - where is the real benefit it's basically a collection of "dead links" because everything was already GCed?

The use of the list is of course within the 60 minutes where the transcripts are still available.
You can then easily upload multiple files and hop through the transcripts using the list as you need them.
So if we assume that we have such a list now, then of course we have to handle the case that a document expires.
Here, my idea was to gray out / disable fetch links, since they will error anyway, perhaps with a hover context hint that the document has expired or something similar.

Of course, there are many alternatives, but i think something like simply instantly removing them can be confusing to a user, since they don't really get feedback on why their list suddenly got shorter.

[nonchris]

You can then easily upload multiple files and hop through the transcripts using the list as you need them.

haven't thought about a highly parallelized usecase. so yeah. this makes sense.

create an issue i guess and feel free to vibe it? ^^'
I have no real stakes in the frontend and honstely no strong requiremnts on the frontend's codequality. maybe mayniklas has different views in that regard...

[pohlarized]

Oh I don't have very high stakes in it either, i was just continuing the design discussion.

My main issue really was that the "Clean input" button was a little misleading and almost made me lose the transcript (at least in a way that i wouldn't have known how to recover it, even if it was still in-memory in the back end).

The rest was just a big list on what it could look like in an ideal world. I think the hotfix i like the most is to call the button "reset" and perhaps color it orange or red. If whoever has authority agrees, I'm happy to add that to the PR.

[nonchris]

I really liked your input.

I mean we got three small, but meaningful improvement (ideas) out of it.
(red buttons are always cool 👀)

Think @MayNiklas is the final authority for the frontend.