Hi,
Sorry for the delay answering. I'll be quite busy next week, so don't
expect high responsiveness.
On Tue, 17 Mar 2015 08:59:31 -0700
spencerone@??? wrote:
> > Alan:
> > We should also keep in mind that language selection must be
> > discoverable by people that might not understand a single word of
> > english. It was among the goals of the list of languages on the left of
> > the languages section: seeing different 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.
> >
>
> Thanks, but keep in mind that these are just high-fi wireframes, so
> there is plenty of room for visual treatment. The form is directly
> influenced by the info.
>
> I see the value in experiential recognition, however, this is a one-time
> use case, though it is arguably the most important one.
That's the point.
> Maybe there is
> an auto-prompted walkthrough the first time Tails is run [if this isn't
> a security issue].
This is being thought currently for other reasons I think, but no clear
conclusion have been reached yet as far as I know.
> Even if people choose not to save settings, for
> whatever reason, they would now know that this section, even if in an
> unfamiliar language, is for adjusting the language. This wont work so
> well for a hand-me-down version of Tails-on-a-stick, though.
>
...which I think we need to keep supporting.
> Or, though it could become annoying, even though it could maybe be
> deactivated somewhere in the settings, what if there is an always-on
> alert/walkthrough instruction to edit the language, or even the other
> settings.
I really don't think that we want to add extra settings that would
split the anonymity set, need documentation and so on. However, why not
to ask first for a language if there is none saved in case we don't
find another satisfying solution.
> This could be a resolution for the guided configuration flow,
> too, where it just runs on startup until deactivated [and it can always
> be turned back on].
>
> We could also do something super simple, like this[0], though that might
> be too simple as well as bare the burden of a click, and ultimately,
> more flow fragmentation.
>
I don't really get the proposal? Do you mean a welcome/check and go
screen with three buttons, one for each set of settings? If yes, how
does it solve the language issue and its discoverability.
> >>> 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.
> >>
> >> Spencer:
> >> 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.
> >
>
> I agree, but it makes the most sense if we have all of the options on
> this first screen. However, the issues with this "all-in-one"
> experience are:
>
> - Possible information overload
> - Saving the more technical settings = security issues
> - Available space
>
> A complete IA outline is necessary
What is an IA outline?
> to effectively determine the impact
> of the first and third issues, with a mockup/flow study, or two, being
> needed to determine the impact of the second issue.
>
Would you like to convey such a study if we agree it's relevant?
> >> However, I understand and
> >> respect the desire to accommodate different use cases and the varying
> >> technical understanding of people by having two separate 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.
>
> An 'Advanced' button is interesting, but we would also need a button to
> enter the guided configuration flow, and the 'Edit' button with two path
> choices addresses this in an effective manner, even if only the language
> options are displayed - though 'Edit' would need a more effective label,
> and then doesn't make as much sense as the questions then become "Would
> you like to configure some other settings than are displayed here?" and
> "Which of these two paths would you like to take to configure the other
> settings that are not displayed here, the "guided" or the "non-guided"
> path?"
>
> If we have the language section separate from the two configuration
> flows, we have the same architectural structure we are exploring away
> from.
Do we agree that we should have the storage section together with the
language one as directly accessible to allow people to unlock their
storage straight away (it they have one).
> Maybe, to cut down on the fragmentation, we have a directly
> editable language section that has an expandable advanced section below
> it,
Looks like quite good. I like the summary of your buttons in
GreeterMinimalFirstScreen.png. Perhaps the expandable section could
display such a summary when not expanded? Or the summary could just be a
button that shows another screen
> and, if the arrow or plus sign is actioned to display the advanced
> settings, the section, in addition to the more technical settings, also
> reveals a button to enter the guided configuration flow - or maybe this
> is simply a link and is always displayed.
>
I like the idea of a "Guided" button that would always be there, e.g.
at the top of the screen and that could be used not only to configure
the advances settings but also to have kind of a "tour" including the
e.g. the storage settings
> >>> 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!
> >
>
> The most common interfaces that I see in our context are:
>
> Columns[1]
>
> and
>
> Tabs[2]
>
> My issue with these are that they clutter the experience with
> unnecessary frames, physically and mentally. Both hide information and
> weaken user trust, as people often have to double check the status of
> things; with security, this can become a problem.
>
This makes sense.
> >> 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...
> >
>
> Unless you are referring to something else [please direct me if you
> are], tchou proposed an accordion interface; this is not what I am
> thinking, at least not visually.
>
> This[3] is what I am thinking. We keep the language settings fixed and
> directly editable.
>
OK. I think we could agree on GreeterAdvancedSettings (with the 2nd
option after the "or" being more coherent with GNOME desktop practices
I think) BUT the storage section should be always displayed IMHO and
not be included in advances settings.
> How fixed is the vertical height of the greeter window?
>
We don't necessarily have to fix its height, we could adapt it
depending on the screen and add a scrollbar if needed. But if fixed it
should be small enough for 10' netbooks (I think something like 500px)
> We could also do an initiation where, unless there are arguments against
> it, people are invited to enter into a more advanced experience, like
> activating 'Developer Options' on Android/Cyanogen, with the setting up
> of the administration password/encryption.
>
I don't get this proposal.
> >> 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.
>
> Yes, and I respect your desire to disclaim the label of "Designer",
> however, unless you are simply implementing decisions made by others,
> you are a designer, as design is to designate. Though, if you
> absolutely reject that title, no worries.
>
I don't absolutely reject a title, just want to be honest about my
background and skills.
> >> 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 further reduces the anonymity set of the user.
> > - some settings, like saving Tor bridges (unencrypted) gives
> > information that highly reduces the anonymity of the user in an
> > adversary gets the device
>
> I look at editing the settings of a device that I own as an
> administrative task. Couldn't this be addressed with the protection of
> an administrative password that decrypts the settings?
>
Yes, this is an option to save some of these settings in the encrypted
storage, if present. That should still be investigated more to know
which setting is relevant and safe to save this way.
To summarize:
- I do agree with proposal "GreeterAdvancesSettings" (if put "Storage"
settings outside the "+")
- we still have to precise how we edit each setting
- we still have to agree on a way to make language discoverable
- should we have a summary of advanced settings displayed upfront (at
least if some diverging from defaults are selected?)
Moving forward, yeah!
Cheers
