Hi, > > 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.
In the .desktop, you had StartupNotify=false Just set this to true and you're done. > > 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). > Why? Why not a wrapper to launch this specific link as amnesia? > > 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. > I support sajolida's remark. The debugging info looks scary. > > 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. > What about an expandable area labeled "Show debugging info that you would include in your bug report" or something like that? > 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? Stupid question: couldn't a task tell the kernel to "reserve" the memory it will need? > > 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. > I think it's fine to tell the user they shouldn't do something else during the upgrade and add this as a requirement. On the long run, perhaps there could even be an "upgrade" mode, selected in the greeter, that would start an upgrade-only session? If I remember well, you can have a GTK application be "system modal", meaning it is the only usable application. >> 12. Explain you need to restart to apply the upgrade. >> I don't remember the phrasing of the last dialog, Why not to force the user to restart, like "You should now restart Tails, click here to restart"? Cheers _______________________________________________ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev