0

I am designing a tool within a webpage where users can check out a dataset, make changes to it, then check the data back in so that another user can work on it. I have covered the eventualities of users ending their session properly, or clicking out of the tool to another page, or becoming inactive when their browser window is still open. All of these situations can lead to the data being checked back in. However, how should I deal with users closing their browser window before they have checked the data back in? We need it to be checked back in relatively quickly (i.e. within a few hours) so that other people can work on it but can't program something to detect that their browser window has been closed because, according to our developers, that would be too "hacky".

The only similar behaviour I can think of is on Microsoft Sharepoint where, if a file is checked out, it remains checked out to the user even if they forget to check it back in, and you have to personally ask them to check it back in.

What is an accepted behaviour to use in this situation? Should we automatically check data back in after a certain amount of time, or leave it checked out and have a way of contacting the user to ask them to properly end their session?

  • I don't think it would be hacky to detect browser close. If this app is using javascript that is exactly what onbeforeunload was made to do. Just prompt the user at that point "Closing the window will check you back in, continue?" – DasBeasto Jul 21 '15 at 15:39
2

From a technical standpoint, you'd use javascript: onbeforeunload

When they close the window, first prompt them to check in (or discard) their checkout.

From a UX standpoint, I'd strongly argue that you never check in automatically. Check in should always be a user-triggered event. There's just no way to know if they forgot vs. they abandoned it.

If you want to be safe, you could implement some of 'draft' save. So once they check out data, clone it as a 'draft'. You could then preserve that draft for later usage. But you don't want to be over-writing the source file with check ins that aren't explicitly fired off via user interaction.

Another option is to allow users to 'steal' checkouts. If someone forgot to check it in, then another user can say "I want to steal this checkout". In that situation, the original user can't check it back in automatically.

1

Leaving it checked out to the user sounds an acceptable solution if there may be a reason they left it checked out.

One option could be to give any user the ability to unlock files but stress that the user that has it checked out would lose any changes by doing so.

Another option would be for users to flag that they want something unlocked, this then prompts the user who has it checked out and if not done so after a certain period of time, the system then checks it in

  • It's more likely to be accidentally leaving it checked out, knowing our users ;-) – Abbie Jul 21 '15 at 16:05
  • The last option is probably more appropriate then. – Varedis Jul 21 '15 at 16:07
1

Thinks will go wrong; users will go on holiday; computers with crush; users will die (or just get a new job).

Therefore anther user MUST be able to do their work when an item is left checked out. So there must be a way to get a checkout undone.

This could be by having an “admin” user with the power to undo checkouts, or by allow any user to undo a checkout. The important thing is that it should not be too easy to undo someone else checkout, and audit must be kept of who did the undo.

I also like the user that did the checkout being sent an email by the system, along with the user undoing the checkout having to enter a comment to explain way they are doing the undo.


Another option is to allow a checkin without a checkout, therefore making the checkout just be hint to anther user, that the given data is in the process of being edited, and that they should talk to x before editing it themselves.

0

Establish a process for "hanging" check-outs to keep the system running

Don't check in data automatically — that would be equal to publishing "work in progress." However, you could certainly check in the original data after a period of inactivity.

Establish a certain threshold for inactive check-outs — if after some time the user doesn't go back to his activity, then send an email alert to the user with a strong CTA to go back and complete the check-in. If no response follows, just check-in the original data — to keep the system running in a stable state.

  • Checking the data in would just mean saving their changes and allowing someone else to continue making changes, not submitting the data. – Abbie Jul 22 '15 at 13:55
  • Oh, then scratch that part please :) However, I'd still recommend the system to handle the "hanging" cases. – Jane Portman Jul 22 '15 at 14:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.