Project locks have proven to be a nightmare for users.
They occur when another user have opened the project or when the project is already opened by the same user.
However, there is no legible way to properly close a project (you must click in MMU left menu), and event if there where, users will forget about that and directly close their browser or something.
I see two solutions we have to investigate:
- Develop a realtime multiuser editing with sockets and all (may be a big peace)
- Have the locks at the annotation level, and not the project level.
Option 2 seem good to me as users will not likely let an annotation edition panel open. I also stress that if two users are editing the same project at the same time, we do not really care witch Mirador state is saved in the end, at least regarding the visual state of the workspace (what windows are opened, the zooms, etc.). For the Manifest list it may be a concern, but I think we can handle that.
Lets brainstorm a bit so we see the path to follow.
Project locks have proven to be a nightmare for users.
They occur when another user have opened the project or when the project is already opened by the same user.
However, there is no legible way to properly close a project (you must click in MMU left menu), and event if there where, users will forget about that and directly close their browser or something.
I see two solutions we have to investigate:
Option 2 seem good to me as users will not likely let an annotation edition panel open. I also stress that if two users are editing the same project at the same time, we do not really care witch Mirador state is saved in the end, at least regarding the visual state of the workspace (what windows are opened, the zooms, etc.). For the Manifest list it may be a concern, but I think we can handle that.
Lets brainstorm a bit so we see the path to follow.