Hi,
spencerone@??? wrote:
> >> spencerone[at]openmailbox.org:
> > sajolida@???:
> > Thanks for working on this. I'll comment on your proposal based on
> > actual tickets that we have to solve.
> No worries :) Thanks for being so inviting!
>
> > #8968: Redesign the "language" section
> >
> > I like the simpler way of displaying all the language options one of
> > top
> > of each other as this would solve #8968.
We should also keep in mind that language selection must be
discoverable by people that might to understand a single word of
english. It was among the goals of the list of languages on the left of
the languages section: seeing diffrent languages names that you
probably know some invite you to click on yours first. I like the
aesthetics of your proposal but I'm afraid it might not address this.
> Still, I would have those
> > options directly editable (without having to click "Edit"). You might
> > have argued in favor of that choice later in the thread, though.
>
> Direct editability would be most appropriate if all of the options were
> visible, including the more technical options, then there would be no
> fragmentation of the configuration flow.
I really think we should go this way: direct editability; less
fragmentation.
> However, I understand and
> respect the desire to accommodate different use cases and the varrying
> technical understanding of people by having two seperate configuration
> flows. Having two paths requires a decision, though, and an 'Edit'
> button is an effective way of addressing this.
>
I really don't think the edit button to be appropriate for the
"Language" section. Why not for the "Advanced" one if we find no better
way.
> > #8976: Consider merging "basic" and "advanced" screens
> >
> > I'm not convinced by the idea of displaying the advanced options on the
> > first screen. And for several reasons:
> >
> > - It adds more information than need to newcomers, while we are
> > working hard to make the default options not harmful in the general
> > case. So with your proposal, someone new to Tails would be faced with
> > jargon such as "Mac Spoofing" with as much importance as "Keyboard
> > Language".
>
> It does add more information for beginners, but, as in the existing
> blueprint for 'Context' in the 'Guided Configuration' flow, what is
> being called jargon is already present as subtext, in this case, as the
> actual description to labels like 'Home & Office'. It also appears in
> 'Check & Go' in the same flow, in addition to other more technical
> options.
>
> Considering this, and in addition to the more technical options
> displayed in 'Check & Go' [the last screen in the 'Guided Configuration'
> flow] it seems appropriate to provide a more comprehensive view of the
> configuration settings by including 'Language' on the same screen.
>
I tent to agree with you on that.
> > - Advanced options might grow bigger in the future, and we might then
> > have problems showing everything on a single screen. Having a dedicated
> > screen for "Advanced" options would be less problematic to this regard.
>
> No problem. All content can be accommodated for. It would be less work
> to know what they all are as early in the game as possible. Is there an
> exhaustive list of these settings, maybe with cited likeleyhoods of
> inclusion?
>
Quoting intrigeri: "We already have in queue at least:
* #6811 (Propose an offline mode)
* #7723 (Make it possible to opt-in for I2P in the Greeter)
* Bluetooth (some patches should land on -dev@ soonish)
* and possibly: LAN access"
> > A solution to both problems could be to rely on "tabs" or "views" as we
> > proposed with Alan on
> > https://labs.riseup.net/code/attachments/download/652/greeter2.png.
>
> I am not a fan of tabs, though that could address space issues.
Why? Please convince me!
> Having
> an expandable 'Advanced' section below the language settings feels more
> appropriate and less fragmented.
>
Tchou already proposed this, and I was not convinced because I didn't
see other examples of such an expandable section in GNOME. But seeing
you also propose it, I'm up for being convinced: if two different
persons think it's the solution, let's explore it anyway...
> > Still, I'm conscious that this might be antagonist to the idea of #8974
> > (Feedback to the user which options are going to be used). But then
> > maybe we don't have to push that information to the user if she doesn't
> > diverge from the default settings.
>
What about displaying which advanced options are checked of the 1st
screen only when they diverge from defaults then? It would address
#8974 (Feedback to the user which options are going to be used) without
confusing newcomers or less technical users.
> I firmly believe that designers, which we all are, are teaching others
> how to learn by creating interfaces that allow people to teach
> themselves.
I like this idea but *disclaimer*: I'm not a designer, I'm a GUI
programmer that try to take UX design into account.
> With this said, it seems appropriate to educate people of
> varying technical levels of understanding what options are available to
> them and what importance these options hold in regard to the intended
> funtion.
> In our situation, this is most effectively accomplished by
> displaying everything upfront
I'm not sure. Displaying everything upfront has:
Pros:
- more discoverability
- easier access to all options
Cons:
- more information to be processed by (new) user
- risk of trying potentially harmful options easily without reading
the doc/searching for the option (this can be addressed by
warnings/strings while editing such options but should be thought!)
[...]
> > #9004: Reword the "remember" options for language settings
> >
> > I'm worried by the fact that you placed the "Save" button below all the
> > other settings. The idea here is the allow for saving the language
> > options only (as all the other ones might have privacy implications).
> > Remember that our last consensus had it as part of the "Language"
> > section. See
> > https://tails.boum.org/blueprint/greeter_revamp_UI/greeter-1st-screen.png.
> > But still, apparently this has to be improved upon, so let's keep this
> > in mind.
>
> Can you expand upon the privacy implications of saving all other
> settings for future sessions, or point to a thread that already has?
- Whatever the content of the option is, saving an option saves
information on the user the device (key) belongs to. If I'm an
adversary that gets a Tails device in Italy, having an italian
language set doesn't give me much information as it's likely most
Tails in Italy have it. On the other hand, any other option saved on
the clear furether reduces the anonymity set of the user.
- some settings, like saving Tor bridges (unencrypted) gives
information that higly reduces the anonymity of the user in an
adversary gets the device
> What are the specfic issues and how do they differ from those presumably
> present with saving language settings and having encrypted storage?
We need to store language settings unencrypted because they are
required to type the passphrase to unlock the encrypted storage (if
present). All the other options we might want to save can be saved
encrypted in this storage because we don't need them before unlocking
the storage.
> Knowing this will help me provide a more valuable and productive
> response.
>
Sure.
> > #8244: Decide if we want to keep the wording "Quick setup"
> >
[...]
> >
> > #8776: Rename "Start" button as "Start Tails"
> >
> > I see that you are in favor of "Start Tails". I'm all for it as well.
> >
> Start Tails :) Though I understand and respect the use of icons for the
> sections, such as 'Language', I would push for no iconography for 'Start
> Tails'. What do you all think?
>
OK for me.
I'm glad to see we start to understand each other better, and to
converge towards a solution!
Cheers
