Project

General

Profile

Feature #15671

Feature #14468: Add VeraCrypt support to Tails

Feature #14480: Fix bugs and UX issues of VeraCrypt support

Improve how Disks is pointed to from the GNOME Shell dialog

Added by sajolida over 1 year ago. Updated about 1 year ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
-
Target version:
Start date:
06/18/2018
Due date:
% Done:

10%

Feature Branch:
Type of work:
Code
Blueprint:
Starter:
Affected tool:

Description

During the user testing of the VeraCrypt beta, people had a hard time understanding the relationship between the button to open Disks in the GVfs monitor message and the message itself.

  • 2 participants thought that still had to type the password in GVfs monitor and then open Disks.
  • 1 participants (and maybe more) thought he had to use Disks to locate the keyfile.

Maybe we can do something about that in the layout of the dialog...

Shell Unlock Dialog Open Disks Button.png View (69.3 KB) segfault, 06/28/2018 01:27 PM

History

#1 Updated by intrigeri over 1 year ago

  • Assignee set to sajolida
  • Target version set to Tails_3.8

#2 Updated by sajolida about 1 year ago

  • Target version changed from Tails_3.8 to Tails_3.9

#3 Updated by sajolida about 1 year ago

  • Assignee changed from sajolida to segfault
  • QA Check set to Ready for QA

After watching the videos again I think I understand the problem better. People thought that Disks was the place where to specify the keyfile and didn't understand that they had to use Disks as a full alternative to GVfs monitor.

I think that the confusion arises from the fact that Disks is presented below all the other unlocking parameters, as if it was the place to specify a keyfile (but not a password for example).

So what about presenting Disks first and not in the list of unlocking parameters?

That could be:

Set options to unlock the volume
================================

The volume Generic Flash Disk (8.2 GB Drive) might be a VeraCrypt volume as it contains random data.

To unlock a volume that uses keyfiles, use _the *Disks* utility_ instead.

Password: [                 ]

[ ] Remember Password
[ ] Hidden Volume
[ ] Windows System Volume

[   Cancel   ] [   Unlock   ]

I'm also:

  • Replacing the button with a link. Now that this appears on top of the dialog despite not being the most popular option, it feels right to try to take less pixels.
  • Saying the Disks utility instead of Disks. See #15669.

#4 Updated by segfault about 1 year ago

  • Assignee changed from segfault to sajolida
  • QA Check changed from Ready for QA to Info Needed

sajolida wrote:

After watching the videos again I think I understand the problem better. People thought that Disks was the place where to specify the keyfile and didn't understand that they had to use Disks as a full alternative to GVfs monitor.

I think that the confusion arises from the fact that Disks is presented below all the other unlocking parameters, as if it was the place to specify a keyfile (but not a password for example).

So what about presenting Disks first and not in the list of unlocking parameters?

That could be:

[...]

I'm also:

  • Replacing the button with a link. Now that this appears on top of the dialog despite not being the most popular option, it feels right to try to take less pixels.
  • Saying the Disks utility instead of Disks. See #15669.

I like it. But unfortunately, links are not supported in GNOME Shell's labels :(
So we will have to use a button or make the whole label clickable or figure out something else.

#5 Updated by segfault about 1 year ago

I implemented the other changes, i.e. moved Disks above the other options and saying the Disks utility. See the attached screenshot.

#6 Updated by sajolida about 1 year ago

  • Assignee changed from sajolida to segfault

Great! Changing the order was the most important part!

Nitpicking: I gave you wrong instructions because of the different syntax between Markdown and Redmine. The GNOME Style Guide uses italic for applications name. So it should be "the Disks utility" and not "the Disks utility". Sorry for the confusion! And if it's a pain to change, please ignore that :)

#7 Updated by intrigeri about 1 year ago

  • Subject changed from Rethink how Disks is pointed to from GVfs monitor to Improve how Disks is pointed to from GVfs monitor
  • Status changed from Confirmed to In Progress
  • % Done changed from 0 to 10
  • QA Check deleted (Info Needed)
  • Type of work changed from User interface design to Code

#8 Updated by segfault about 1 year ago

  • Subject changed from Improve how Disks is pointed to from GVfs monitor to Improve how Disks is pointed to from the GNOME Shell dialog

#9 Updated by segfault about 1 year ago

Nitpicking: I gave you wrong instructions because of the different syntax between Markdown and Redmine. The GNOME Style Guide uses italic for applications name. So it should be "the Disks utility" and not "the Disks utility". Sorry for the confusion! And if it's a pain to change, please ignore that :)

Fixed on the branch based on upstream master, so that this will be correct when merged in upstream. I also fixed it in my branch based on the version we use in Tails, but I won't build a new package just for this.

#10 Updated by intrigeri about 1 year ago

  • Priority changed from Normal to High

segfault wrote:

Nitpicking: I gave you wrong instructions because of the different syntax between Markdown and Redmine. The GNOME Style Guide uses italic for applications name. So it should be "the Disks utility" and not "the Disks utility". Sorry for the confusion! And if it's a pain to change, please ignore that :)

Fixed on the branch based on upstream master, so that this will be correct when merged in upstream. I also fixed it in my branch based on the version we use in Tails, but I won't build a new package just for this.

If I understand correctly this will be a translatable string change so I'd rather see this applied in the RC and not during the freeze, in order to avoid the strings becoming fuzzy. There might be other reasons (packaging improvements from #15521) to rebuild this package anyway.

#11 Updated by segfault about 1 year ago

  • Priority changed from High to Normal

I included this in the new gnome-shell package built as part of #15221.

#12 Updated by segfault about 1 year ago

  • Status changed from In Progress to Resolved
  • Assignee deleted (segfault)

I think we are done here, it will be upstreamed along with https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/126 (tracked on #15222).

Also available in: Atom PDF