[...]
> > For the walkthrough: as you write, the "Step by step" is definitely the
> > best choice. I like the fact it is accessible from the 1st screen as in
> > your mockups. I doubt however that the link is better than a button, as
> > it may be less clear that it is an action.
>
> Word. Though it isn't the internet, a hyperlink should be the most
> familiar actionable item to people, as it only has the one appearance.
> This is in opposition to buttons, which come in many shapes and sizes,
> and, as a result, have a lessened probability of functional clarity and
> will instead rely on people's familiarity.
>
> Although the native Gnome styling would most likely resolve this
> lessened functional clarity, having the Guided Configuration path
> accessed through a button will create visual conflict as the two buttons
> will be competing for people's attention. I would recommend, even
> though the two paths are equal, to emphasize the 'Start Tails' path as
> the major path, with the actionable item being a button, and to
> emphasize the 'Guided Configuration' path as the minor path, with the
> actionable item being hyperlinked text. This seems like a more fair
> balance of attention given that the 'Guided Configuration' path is the
> least occurrent. (This might not be reflected in the examples)
>
> We could use different wording. 'Learn more about Tails' was chosen
> because the of the multiple functionality provided by the Guided
> Configuration flow dialogs, which, although it emphasizes settings
> configuration as the main focus and education as the minor focus, places
> the educational 'Introduction' or 'About Tails' section first.
> I like the "Take a tour" wording, which seems me to make clear the user
will be guided in the choices, rather than "learn more about Tails"
which sounds me like documentation.
> We could also use a button[0]. However, the main issue with this would
> be the missed opportunity for people to have a better understanding of
> the function before clicking. With the hyperlink, we can more easily
> include a short and descriptive instruction text. But with buttons,
> descriptions can make things seem crowded, be it the button label or
> accompanying text. (This could also be resolved by proper associative
> grouping of the elements and not need to be explicitly stated)
>
> [0] Two.Buttons.png
> I like this two buttons very much as it seems me to:
- make it clear there are two alternatives
- make emphasize the suggested one
However, I'm not opposed at all to another design
> >>
> >> Start Tails Button Location
> >> ------------------------------ > Here[2] are some examples to help visualize. The more functional
> options are in context below.
>
> [1] Welcome.to.Software.png
> [2] Action.Bar.Location.png
>
As written before, I only have a little preference on and I think you
should judge yourself/with other's help!
> >> Settings Labels
> >> ------------------
> >> Should the settings sections be labeled with either two or three
> >> labels?
> >>
> >> • Two
> >> • Three
> >>
> >
> > I have a little preference for the "Three Settings Section Labels"
> > proposal as it looks more clear to me, and thus quicker to access the
> > right setting.
> >
>
> Word. Three is good, as there are three settings. However, my question
> is, are all of the settings in the third section similar, or are they
> grouped as miscellaneous?
They are somehow similar, as they are the settings to select the
level/type of anonymity you want, as opposed to the "language" section
which is to adapt the interface to your culture.
[...]
> Four elements isn't going to hurt anybody, and could actually help if we > pack more technical settings in there, but three is a magic number.
> However, four elements becomes three if we separate the action bar from
> the canvas, whether it be in the header or the footer, classifying
> 'Start Tails' as the fourth macro-level function.
> I get the idea of reducing the number of steps to see, but making them
more easy to understand seems me a good reason to add a label even
though it looks like one more step.
If you think it's good to visually have three elements, I'd be for
separating the action bar from the canevas.
> If we do feel strongly about using three section labels, what is the
> more appropriate name for 'Settings'?
That's a good question. Privacy settings?
> More specifically, what kind of
> settings are in this group? How would we describe/label them?
> 'Settings' doesn't seem good enough if we are going to be that specific.
> We currently have here:
- windows camouflage (might be removed in next Tails): make Tails look
like windows to look less suspicious in places like Internet cafes
- spoof MAC: randomize hardware network card address of not (randomized
by default, but it my be good to disable it e.g. if using a public
computer)
- network configuration: this allow to use bridges or other pluggable
transport to access the Tor network where it's censored
> >> Label Icons
> >> ---------------------
> >> Should icons accompany either the section labels or the line item
> >> labels?
> >>
> >> • Section
> >> • Line Item
> >>
> >
> > I do like the "Section" labels. I like very much the big section icons
> > shown on "Icon, Text, & Info Buttons" and "List Item Buttons" in the
> > "Other Options" proposal. They give quickly recognizable info, look
> > beautiful, and do not waste space as they only add horizontal content.
> >
>
> The icon/text combination is the most universal and seems most
> appropriate for the line items.
>
> People who understand the settings options can logically arrive at an
> understanding of the sections. However, people who understand the
> sections can't then logically arrive at an understanding of each option,
> or any option, really.
>
> Tails currently uses colored and monochromatic icons to accompany line
> items for almost every list, probably for a similar reason to what I
> give below.
>
> Horizontally, the width of the line items align to other dialogs in
> GNOME/Tails, though I did tighten it up a bit. Be careful, though, as
> more options are added to the technical settings list, eventually the
> entire dialog will look way too tall and skinny.
> I'm not sure to understand what you mean here. You're explaining why
you think there should be no section icons?
> > I do not understand with "Section" label icons are mutually exclusive
> > with the "Line Item" label icons. Both seem useful to me.
>
> Right, the two are not exclusive of each other. The thought behind
> having icons accompany the line item labels and not the section labels
> is, for example, the visual conflict that arises between the 'Encrypted
> Storage' lock icon and the 'Storage' section label icon in the enclosed
> examples, both contextually and compositionally, when placed so close
> together.
>
> This happens with all of the sections and seems to be common in most
> systems. I do have a strong preference for icons on only the line
> items, however, I did my best to try and resolve this with larger
> section label icons, so as not to miss out on a cooler and more visually
> functional resolution. Ultimately, I do not feel they are as strong as
> the options with no section label icons, as the list items can stand out
> and take center stage as their icons help communicate each of their
> respective purposes, but you all can take a look and share your
> thoughts.
>
> >> Close Greeter
> >> ---------------------
> >> Should the Greeter have the option to be closed?
> >>
> >> • Close
> >> • No Close
> >>
> >
> > I have a little preference for the "No Close" option. The only event
> > that this button can trigger to close the greeter would be a reboot
> > (and thus, displaying again the firmware and the syslinux menu). Even
> > though it would be technically possible, it may be confusing to the
> > user. If we put such a button, then it should perhaps be clearly
> > labeled as a "Restart" button.
> >
>
> Word. No Close[x]. A 'Restart Tails' button/link might come in handy,
> should people want to switch modes.
> OK
> >> Other Options
> >> ---------------------
> >> Should we explore other Greeter options?
> >>
> >> • Icon Buttons
> >> • Icon & Text Buttons
> >> • Icon, Text, & Info Buttons
> >> • List Item Buttons
> >>
> >
> > I very much like the "List Item Buttons" look. I'm not sure how you
> > imagine it would work however. I see it as only visual addition to the
> > "Openface" proposal, where each individual setting would be clickable.
> >
>
> Exactly; with either a pop over or a more properly embedded/housed
> switch. We could also do this[3], though it would add some vertical
> space. (Just thinking that the 'Learn More' links to the documentation
> should be included - and an 'Administrator' form)
>
> Exploring a more image focused approach vs a more text focused approach,
> however, created a lot more imbalance than expected. Also, in addition
> to the unusual use of columns, the size and use if the icons doesn't fit
> into GNOME HIG very well. And the 'Storage' section doesn't have the
> appropriate space needed for an 'or' to help clarify that the button
> does not execute the contents of the form field (the order is the first
> of two things needed to effectively confirm this).
>
> Here are some examples[4]. My recommendation is Option 1. Option 1A is
> closest to 3.14 standards, Option 1B is the clearest and most balanced
> (and could easily include a 'Restart' button), and Option 1Hybrid is the
> best balance between the desired size, function, and context.
> 1A looks very clean to me. 1B would be fine but looks less "modern" and
GNOMEy.
> I do not recommend Option 2 for reasons touched on above - but feel free
> to dig.
> I do agree with you that they are visually less clean.
*
When we'll have polished all remaining questions, I think we should:
- make a summary of the decisions so that we can ask others to review
them
- have a mockup that I can build a prototype implementation from
- dig into the detailed wording and icons for each option
I'm looking forward to see all this for real. It looks very promising
to me!
