default autostart URL starts not the most recent commit

[volodymyrss]

Description

I do not know if this should be classified as a bug, but two people stumbled on this already.

Auto-starting new session as so:

https://renkulab.io/projects/vladimir.savchenko/oda-sdss/sessions/new?autostart=1

Starts session with a commit used last time, and not with default commit. It happens completely smoothly, I did not notice any warnings.

When I look here:

https://renkulab.io/projects/vladimir.savchenko/oda-sdss https://renkulab.io/gitlab/vladimir.savchenko/oda-sdss

I naturally see the latest commit. But it's not what is started.

[lorenzo-cavazzi]

We have a (rather aggressive) autosave system to prevent losing content. It creates autosaves whenever sessions are closed (either manually or after the 24h timeout) and there is any non-committed or non-pushed code. When users press autostart, the system checks for any existing autosaves, and it restores the last one automatically. Actually, any running session takes priority, then autosaves, then the latest commit.

I see how this may be confusing in some scenarios, especially if many users work on the same branch. It's hard to find a good compromise since some users complain about losing content without autosaves, while others prefer starting from the latest clean commit.

My advice is to avoid using autostart for recurring users. It's primarily useful for demonstration or to share work at a specific timestamp by including branch/commit in the link. Otherwise, the "New session" page gives more control. You can expand the section for selecting branches and commits to understand what would be in the session.

P.S. we tried to hide most of the complexity behind sessions and autosaves, but it turns out to be confusing. We will revisit all this workflow soon so that users better understand what is going on.

[volodymyrss]

We have a (rather aggressive) autosave system to prevent losing content. It creates autosaves whenever sessions are closed (either manually or after the 24h timeout) and there is any non-committed or non-pushed code. When users press autostart, the system checks for any existing autosaves, and it restores the last one automatically. Actually, any running session takes priority, then autosaves, then the latest commit.

I see, thank you.

But, if I am interpretting correctly, it is not what I observe. Right now opening https://renkulab.io/projects/vladimir.savchenko/oda-sdss/sessions/new?autostart=1 leads to:

I.e. what is opened is not an autosave and not the latest commit. It's creating a new session - so it's new taking a running one.

I see how this may be confusing in some scenarios, especially if many users work on the same branch. It's hard to find a good compromise since some users complain about losing content without autosaves, while others prefer starting from the latest clean commit.

It is hard to account for all cases.

I see the value of "resuming" sessions by starting autosave. But for me, it would be natural to have an explicit confirmation in this case. Something like "We have found some unfinished work, do you want to resume it instead?". I suppose users are used to this sort of messages, they come up in plenty of software.

In our case, it's not exactly that users work on the same branch, just just open the sessions starting from the same branch. And then checkout and push new one if needed. This seems to be the simplest flow to develop starting from the shared master. An auto-start URL is useful for sharing repository to propose reuse and reproducibility.

I realize we could suggest to fork repository, or create branch before starting session, but it's more complex, with potential for other issues and misunderstandings.

My advice is to avoid using autostart for recurring users. It's primarily useful for demonstration or to share work at a specific timestamp by including branch/commit in the link. Otherwise, the "New session" page gives more control. You can expand the section for selecting branches and commits to understand what would be in the session.

Autostart opens by clicking the most obvious "start" button:

It's very tempting to click it. It's hard to recommend our users to avoid clicking such an obvious button.

P.S. we tried to hide most of the complexity behind sessions and autosaves, but it turns out to be confusing. We will revisit all this workflow soon so that users better understand what is going on.

Thank you the the heads-up!

[ciyer]

Thanks for this feedback.

The situation you have looks like you started a session on 0f1f and made some changes that were never committed. The session would still report that it is based off that commit, but I expect that git status would report that your checkout is dirty.

It's clear to us that the current UX is unsatisfactory, but I just want to briefly explain how and why it came to be.

But for me, it would be natural to have an explicit confirmation in this case. Something like "We have found some unfinished work, do you want to resume it instead?".

This is what we initially started to do, but, to add to what Lorenzo said, the way the backend of the autosaves is implemented, if users do not start on their autosave, the autosave information is lost forever. So, faced with that choice, a user will probably want to see what unsaved work they had before deciding if it is ok to throw away, and here, again because the way the backend is implemented, the only way to see the unsaved work is to start a session. We also wanted to keep a notice to the user that they were started on an autosave visible for the life of the session, but that fact was lost once the session had been started.

This is a long way of saying that the UX around sessions was highly constrained by the technical limitations that were in place at the time it was implemented. But the good news is that we are aware that this is far from ideal, and we have been working on removing at least some of these restrictions and are now working on redesigning the UI flow around sessions.

Given the wide interest around this, we will try to organize a public presentation of our plans and give others an opportunity to provide feedback before we implement anything.

[volodymyrss]

Thanks for this feedback.

I am glad to give feedback, and I want to stress that I am just reciting my (and my colleagues) experience. Clearly, I have a limited idea about what is actually happening, and I appreciate that the experience of other users differs.

The situation you have looks like you started a session on 0f1f and made some changes that were never committed. The session would still report that it is based off that commit, but I expect that git status would report that your checkout is dirty.

That's right, it's dirty.

I misunderstood, I thought that the auto-save to branch and saving terminated sessions is the same thing.

But, please correct me if I am wrong, I am interpreting now there are two kinds of auto-save: one with commit to auto-save branch, and another one which keeps dirty state by other means. Or are these two mechanisms related?

It's clear to us that the current UX is unsatisfactory, but I just want to briefly explain how and why it came to be.

I am sure there was a process and some reasoning behind it, but it is apparently still opaque to me. Sorry for asking too much details, maybe if I understand the problem better I will be able to advise our users better even after the UX change. It is a rather unique challenge, I appreciate.

But for me, it would be natural to have an explicit confirmation in this case. Something like "We have found some unfinished work, do you want to resume it instead?".

This is what we initially started to do, but, to add to what Lorenzo said, the way the backend of the autosaves is implemented, if users do not start on their autosave, the autosave information is lost forever. So, faced with that choice, a user will probably want to see what unsaved work they had before deciding if it is ok to throw away, and here, again because the way the backend is implemented, the only way to see the unsaved work is to start a session. We also wanted to keep a notice to the user that they were started on an autosave visible for the life of the session, but that fact was lost once the session had been started.

Is it possible, in the future, to always auto-save in a branch, and start session from that branch? For me, this would be a natural experience. The problem is only that new session would not be at master. But if an appropriate warning and a choice is given to the user, it's clear. It seems like you already have much of this functionality: auto-saving to branches (but not at the session end?), starting from branches.

This is a long way of saying that the UX around sessions was highly constrained by the technical limitations that were in place at the time it was implemented. But the good news is that we are aware that this is far from ideal, and we have been working on removing at least some of these restrictions and are now working on redesigning the UI flow around sessions.

Given the wide interest around this, we will try to organize a public presentation of our plans and give others an opportunity to provide feedback before we implement anything.

That would be great! Also, if you plan some UX research and need some volonteers, let us know!

[lorenzo-cavazzi]

We are now planning for more radical changes to autosaves to avoid confusion. Having feedback from users would be great!

Also, if you plan some UX research and need some volunteers, let us know!

@volodymyrss Is this offer still valid? 😏

[volodymyrss]

We are now planning for more radical changes to autosaves to avoid confusion. Having feedback from users would be great!

Also, if you plan some UX research and need some volunteers, let us know!

@volodymyrss Is this offer still valid? smirk

Yes, sure, myself and @andriineronov could contribute I think. Maybe we can involve other people too. What did you have in mind for the process?

[lorenzo-cavazzi]

@volodymyrss We are verifying the feasibility of removing the branch based autosaves and keeping k8s private volumes around after users terminate their sessions. There are a few technical challenges.

As soon as we pin down what we can realistically do (within 1 or 2 weeks from now), we will share a draft here https://github.com/SwissDataScienceCenter/renku-design-docs and ask you to comment. After finalizing a proposal, the dev team will start working soon on that (the following 3-weeks sprint or the next one, for a total duration of 6 weeks) and we will ask you for feedbacks on prototypes.

On your side, that would mean:

• Commenting the draft before it's finalized to be sure the solution is in line with users' expectations: better to limit it to 1 or 2 people, effort varies but it's limited to the time spent on reading the document and providing/answering comments, probably a couple of hours (example of documents).
• Testing one or two prototypes during the implementation phase to give early feedbacks: a couple of people for 1 or 2 rounds, probably joining a ~1 hour long meeting.

[volodymyrss]

* Commenting the draft before it's finalized to be sure the solution is in line with users' expectations: better to limit it to 1 or 2 people, effort varies but it's limited to the time spent on reading the document and providing/answering comments, probably a couple of hours ([example of documents](https://github.com/SwissDataScienceCenter/renku-design-docs/tree/main/feature-pitches)).

* Testing one or two prototypes during the implementation phase to give early feedbacks: a couple of people for 1 or 2 rounds, probably joining a ~1 hour long meeting.

Sounds good! Then it will be myself and @andriineronov. Let me know!