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!
