Consider saving data to just created persistent storage on restart
NOTE: This is one of a series of usability issues that arose from the TAILS OS training workshop on March 19th, 2016 in New York City.
Currently, when creating a persistent volume, one has to restart before using it, as per the documentation: https://tails.boum.org/doc/first_steps/persistence/configure/index.en.html. Unfortunately, when people I've trained create a volume, their immediate assumption was that persistence was ready as soon as they set it up. If there is a way to remove the need to restart, that would vastly improve the experience of creating persistent volumes and keep people from becoming frustrated when they create a persistent volume, set up a bunch of things, then restart only to see that they have to go through it all over again.
#1 Updated by intrigeri over 2 years ago
- Status changed from New to Confirmed
Yes, this would be great!
I suspect it would be trivial to implement a PoC for just what this ticket asks for, and then the hard part will be to figure out the list of things that can possibly go wrong (possibly nothing, possibly something nasty and non-obvious). The latter was never done AFAIK, which is why we're still requiring a reboot.
If there is a way to remove the need to restart, that would vastly improve the experience of creating persistent volumes and keep people from becoming frustrated when they create a persistent volume, set up a bunch of things, then restart only to see that they have to go through it all over again.
Note that even with messaging around the need for a reboot after setting up persistence, we still now see many users in training making the mistake of thinking persistence is active and ready as soon as they finish the initial configuration before rebooting. 100% of the users I train come from a Windows and Mac background where when they see macOS or Windows tell them "you need to reboot" they don't and experience no consequence and thus, are conditioned to ignore reboot notices unless they're forced to by someone from tech support.
- Subject changed from Automatically activate Persistent Volume Upon Creation to Activate persistent storage without the need to restart
I can't agree more with huertanix!
During the user testing of the Additional Software beta several participants failed to understand that they had to restart for the persistent storage to start storing data. Of course, we could improve the message after the persistent storage is created to explain this better but the root problem is that people expect the persistent storage to store whatever they already did as soon as they activate one of the feature.
For example, P2 failed to understand what happened even after restarting twice.
- He connected to his Wi-Fi.
- He created the persistent storage, activated the Network Connections feature, and understand that he had to restart.
- He restarted and wondered why the Wi-Fi was not connecting automatically.
- He restarted again after some time (as part of a task in the testing).
- He was puzzled when the Wi-Fi connected automatically on the second restart:
« On the second use it connected automatically. There's something I didn't understand... »
The cheapest possible fix (from a dev perspective) would probably be to lock down the system once persistence is set up, i.e. effectively force users to reboot.
Regarding enabling persistence immediately, that should be doable but:
- It'll go wrong at least for files that are already open, e.g. if a Pidgin account is started already, we might copy the corresponding files to persistence (and get them back on next boot), but any further change in the Pidgin UI won't persist. That would create quite confusing UX.
- IIRC some of our session initialization is done differently depending on whether persistence is enabled or not (e.g. the GNOME bookmarks). All this code would need to support being re-triggered and do the right thing when run a 2nd time. Otherwise the user will be left in a session that's of a 3rd kind, somewhere in between "no persistence unlocked" and "persistence unlocked", which may be confusing from a UX perspective (once we remove the need to reboot, one would expect the session to of the "persistence unlocked" kind) and increase our maintenance costs (more complex state machine).
I might be overly pessimistic but I'm worried that we won't do a good enough job at this and we'll end up setting user expectations we can't be up to, which would result in poor UX too (probably better than the current state of things, but the marginal UX improvement might not be worth the dev cost).
So at this point I'm very much tempted to lower our ambitions here and only force the user to reboot.