Hi,
sajolida@??? wrote (12 Dec 2013 11:02:57 GMT) :
> 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!
Thank you for testing.
> 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 :)
We'll see :)
> 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.
Done in feature/incremental-upgrades-integration (3d9eae7).
> 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.
I have no idea how to plug with GNOME's "application is starting"
mechanism, but I can have a look and evaluate how painful it is.
Please file a ticket assigned to me, with category = "Incremental
upgrades". Unsure if this will make it as part of phase three yet.
> 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.
FTR, we're talking of strings like:
copy <a href='%{details_url}s'>this link</a> and open it in the
browser to learn more.
The technical limitation is that the user under which the upgrade
frontend runs has no rights to instruct the browser (run by `amnesia')
to do anything (and no, I don't want to set up a wrapper that allows
the former to run stuff with sudo as the `amnesia' user).
I have implemented exactly what (I understood from what) we have
decided together. Is your current proposal:
copy <a href='%{details_url}s'>%{details_url}s</a> and open it in
the browser to learn more.
... or anything else? I'm happy to change this, once I know why
and how.
> 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.
Agreed. Seems easy to implement with zenity's --ok-label
and --cancel-label options. Would you please file a ticket assigned to
me, category = "Incremental upgrades", parent ticket = #6014?
> 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.
Most ETA's I see displayed are seriously wrong, so I'm not convinced
it generally helps at all UX-wise. Is it really considered as a best
practice these days to display an ETA along with progress bars for
long operations?
> How hard would that be?
I think that having "an ETA" displayed while downloading is easy).
The harder part is making it accurate enough to be marginaly useful.
There might be good algorithms available to do that, but the software
I use apparently don't use these :p
> But that's not a blocker for the initial release, I'd say.
Sure. This could still be worth a low-priority ticket (not assigned to
me, and not part of phase three this time). It might even be tagged
"Easy", given our current definition.
> 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.
Seems totally doable as part of phase three. Please file a sub-task of
#6014.
> 7. Fix %{target_url}.
> I saw a "%{target_url}" string in the error message when a download fails.
Right. I believe I've fixed this a few days ago with commit e94431,
which is part of Tails-IUK 0.11, and therefore of Tails 0.22.
> 8. Hide the details of the error by default.
> The technical details of the error will be of little use for most user.
At least for a while, I think that any such error should be reported
as a bug, so in the current state of things I beg to disagree with
this statement.
> 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.
I agree it will be nicer this way once this code is tested more
broadly, that is, after it is enabled by default, and most bugs are
fixed. Once such errors will be more likely to be caused by issues on
the user's side (e.g. network problems) than by bugs in our software,
I'll like your proposal very much. IMHO this is worth a normal
priority ticket, in the "Incremental upgrades" category, but not as
part of phase three. Could possibly be assigned to me, but I'm not
asking for it.
> 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'm unsure how it can possibly work in practice, but I'm curious and
willing to give it a try. Could you please provide an example of what
you would like for #9, so that we can evaluate something
more concrete?
Also, assuming we agree this is the way to go, will you provide these
summaries as part of writing the doc, or should I schedule time for
this after the doc is written?
> I think a combination of comment #3, #8, and #9 are a blocker.
I don't really see what #8 has to do in there, which probably means
I have misunderstood something you wrote (or didn't). You think this
combination is a blocker, so this must be important. I want to avoid
reacting (possibly defensively ;) on what would be guesses from my
part => please elaborate.
> Let's find a good compromise...
Sure we will! :)
> 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).
I'll assume you are talking of download errors here.
First, well, *you* are supposed to write this doc, so I find it
strange to read my crapy draft reviewed (I'm honored that it looked
like something worth commenting on, though ;)
I only quickly drafted something so that you have an idea what you
should talk about, in the hope it might be helpful, but I'm certainly
not considering it's a done thing. Feel free to improve, rephrase,
rewrite, and/or delete anything in doc/upgrade/error/* :)
It's way easier to explain how to restart Tails, that to document how
to restart the network only and wait for it to be ready. This is why
I wrote it this way.
In case there was a misunderstanding, or perhaps a failed attempt at
second-guessing what I didn't write: this advice has nothing to do
with memory, as least this was not what I meant when writing it.
Does it solve your concern regarding this phrasing?
Slightly OT, but still: the current code checks that there's enough
available memory before doing anything, but sure, if the user starts
hacking huge pictures in Gimp while the download is in progress, it
may fail. IMHO this is a UI or doc issues: we should probably tell the
user right away, when proposing them to perform an incremental
upgrade, that they should simply wait, and avoid starting
applications: doing so might have the download fail (or leave their
Tails system in a broken state, if this happens while the upgrade is
applied). Thoughts, phrasing proposals?
> 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.
It took me a few minutes, but I now understand why I didn't think of
this at all, and why this whole topic looks very strange to me.
I think I can explain. On the one hand, the current state of the UX
suggests that one may freely use Tails during this process, with no
risks implied; the timing of the "we're now going to shutdown the
network" warning shows up clearly suggests this. On the other hand,
the current code (and its author, and its design) doesn't take this
requirement into account. Well.
1. I'd be pissed off to see this requirement explicitly added *now*.
I'm very sorry that the current UI has been suggesting, for more
than a year, that I was already, and implicitly, taking this
requirement into account.
2. I think we really have to make this all more consistent, starting
with avoiding making promises we can't hold (well, these promises
are not explicit, but the current UI suggests it, which is enough
to be a problem IMHO). See below.
> 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.
The first one could be done right now, as part of phase three.
It's just a sentence to write and add, feel free to file a child
ticket of #6014, assigned to me. This could go with a general warning
against running apps during the upgrade process, and generally solve
the mismatch between the code and what the UI suggests.
The second one encourages people to do things while the upgrade is
downloaded and applied, which I'd rather not to. If one wants to go
this way, IMHO one would at least have to check available memory
again, before displaying this confirmation dialog, and think seriously
of the consequences of trying to support this usecase.
> 12. Explain you need to restart to apply the upgrade.
> I don't remember the phrasing of the last dialog,
FTR (and to help others participate in this discussion), it is:
"<b>The system was successfully upgraded.</b>\n\n".
"The Tails partition on the USB stick is not write-protected ".
"anymore for this working session.\n".
"This is not safe, and you should restart Tails <b>as soon as ".
"possible</b>.\n\n".
"Restart the computer <i>now</i>?"
> 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.
My feelings don't fully agree with thist: IMHO the security issue
seems enough of a reason to reboot, and I'm not sure if adding more
reasons will help in any way.
... but I trust you more than myself to make excellent decisions on
this kind of things, so I won't block on it. Please propose a phrasing
you find better, and I'm happy to take it.
I just did that to start with, but it clearly doesn't address your
concern:
- "<b>The system was successfully upgraded.</b>\n\n".
+ "<b>The Tails device was successfully upgraded.</b>\n\n".
> Conclusion: most of that is actually editing work that I should really
> start working on, probably in parallel with the user documentation.
Yep.
> I'd also like to hear how feasible the code things are with respect
> to our deadlines.
Everything I've agreed to do above is easy and can definitely be done
in time. For the rest, well, we have to finish discussing it first.
> Regarding deadlines: will we be able to ship such fixes in Tails 0.22.1?
IMHO, everything I've agreed to do above will be ready in time for
0.22.1, yes. I don't think coding tasks will be a major blocker.
My bet is that it'll mainly depend on how much feedback we get this
time, on other issues discovered, on user doc, on how fast things are
discussed / tested / decided, and on reviewers' availability.
> 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
I would very much like to see this happen: enabled by default in
0.22.1, so users will be proposed to do it when 0.23 is out.
Technically, switching to a entirely new security upgrade warning
system (feature/incremental-upgrades-integration) does not meet our
point-release criteria. I've suggested we do it nonetheless when
posting the 0.22.1 release schedule a few days ago, and I've seen no
objection raised yet.
> because I can't seen any point update in our calendar until Tails
> 1.1. Rock'n roll!
I'm starting to think that we should not prevent ourselves from
providing incremental upgrades for major releases as well. I've not
dared updating the design doc in this direction yet. I propose we try
this for every release until 1.0, and see how it goes in practice.
(Presumably, the 1.0..1.1 diff will be that huge that it's useless to
publish an IUK for it.)
Also, note that there is some lag involved by all this: if we ship
some crappy code in version N, and discover issues only six weeks
later when people use it to upgrade to N+1, then it's too late to fix
it in N+1, and it can only be be fixed in N+2. So, we really have to
find bugs in release candidates.
Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
