intrigeri: > now is the time to test this stuff live and detect remaining issues > before we enable it by default for all Tails users; here's how: > > https://tails.boum.org/news/test_incremental_upgrades/ > > I promise there will be another incremental upgrade from 0.22~rc2 to > 0.22, so if this works for you, then you'll be able to easily upgrade > to 0.22 :)
Finally, I managed to run this all the way without trouble. So first of all I have to say that the mechanism worked like a charm. Congrats! Nonetheless, I identified many user-interface issues. Most of them have to do with phrasing, a couple of them with interaction. I hope I am not raising too many issues and piss you of :) 1. The menu launcher is called Tails Upgrader. While doing for initial brainstorming on the documentation I realize that we will still have to document both processes: full upgrade and incremental upgrade. They are very different kind of beasts, so the differences between the two need to be explain and we should use different terminology. We can try to stick to "full upgrade" and "incremental upgrade" for the time being. But then the menu launcher should be rename "Tails Incremental Upgrader" or something like that. That's not a blocker from a technical point of view but it might prevent writing doc with a coherent terminology. I'm ashamed I'm raising that issue so late in the process, and I hope it makes sense. Hopefully some day we will all be less busy and more able to write the doc before writing the code :\ 2. No feedback while looking for upgrade. When the menu launcher is first started it takes several seconds before having any visual feedback. This can be really confusing. How hard would it be to display a spinner or something? That looks pretty important to me. 3. The "click link" in the dialog messages are unclear. I know we already talked about that, so feel free to remind me of the technical limitations here but I thought we agreed on displaying the full path of the link so people can type it in. 4. The buttons labels should be more explicit than "Yes" and "No". Every time we have buttons in a dialog, we should try to make their label as explicit as possible. For example, in the first dialog it could be "Cancel" and "Upgrade", or "Cancel" and "Try again" on network errors, or "Restart now" and "Restart later" once the upgrade is over. 5. Give an ETA while downloading. It is good to have a progress bar while downloading the IUK, but it would be much better to have an ETA. How hard would that be? But that's not a blocker for the initial release, I'd say. 6. Give an explicit title to each dialog. I don't have all the precise examples at hand but the title of the dialog should be more explicit. For example, instead of "Error", say "Error while downloading the upgrade" or something like that. 7. Fix %{target_url}. I saw a "%{target_url}" string in the error message when a download fails. 8. Hide the details of the error by default. The technical details of the error will be of little use for most user. It is mainly displayed to be copy & pasted for debugging purpose. So we should hide it by default and have a expandable area and a "Show technical details" button or similar. 9. Display a summary of the documentation page in error dialogs. As a follow-up on comment #3 and #6, a summary of the documentation, that would allow most users to understand what happened and what to do directly from the dialog. The summary would also make it clear when it is required to really check the documentation for more info. I think a combination of comment #3, #8, and #9 are a blocker. Let's find a good compromise... 10. Mention lack of memory as a possible cause of error. In the documentation "This is probably caused by a network problem. Restart Tails." doesn't seems really logic at first sight. It should mention to check the network connectivity, and also that a lack of memory could be the cause of the error, and that's when restarting Tails makes sense (even though maybe not only). 11. Do not disable the networking without warning. At the end of the process the network is disabled: we should warn the user about that as this might be unexpected and problematic. So either we warn them at some point in the process that this will happen at the end, for example in the first dialog before choosing to do the upgrade, either we add another confirmation dialog between the download and the upgrade. I prefer the second one but it implies more code. I think this is important but not a blocker. 12. Explain you need to restart to apply the upgrade. I don't remember the phrasing of the last dialog, but I think it says that you need to restart to get the network back and for security reasons but it should be made more explicit that the upgrade is not running yet. For example, the About Tails page still displays the old version and that's expected. So, the sentence "The system was successfully upgraded" could maybe be replaced by "The Tails device was upgraded, restart to be on the new version" or something like this. Conclusion: most of that is actually editing work that I should really start working on, probably in parallel with the user documentation. I'd also like to hear how feasible the code things are with respect to our deadlines. Regarding deadlines: will we be able to ship such fixes in Tails 0.22.1? What do you mean exactly when you say "enable it by default for all Tails users"? Are you talking about Tails 0.22.1 → Tails 0.23 ; because I can't seen any point update in our calendar until Tails 1.1. Rock'n roll!
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev