Hey hey hey,
>>
>> Spencer:
>> Structure Types
>> ---------------
>> There are three different structures.
>>
>> • Step-by-step - Guided walkthrough
>> • Show/Hide - Hidden off-screen or behind on-screen element
>> • Openface - Full display
>>
>
> Alan:
> I think that we already decided to have two different paths:
>
> - the default path with quick access to the settings
> - the walkthrough for newbies
>
> For the default path: I think that "Step by Step" is not possible
> because it takes too much clicks and screens. I think that both
> "Show/Hide" and "Openface" could work. I have a strong preference for
> "Openface" as it gives quick access to the settings. I think that the
> visual clutter can be lowered by a good hierarchy of the information
> (that we already heavily discussed) and by a good design (I love some
> of your mockups!).
>
Word. "Openface" it is!
>
> 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.
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
>>
>> Start Tails Button Location
>> ------------------------------
>> Should the location of the button be in either the top Greeter frame
>> or
>> the bottom of the Greeter canvas?
>>
>> • Top
>> • Bottom
>>
>
> I have a little preference for the top position as:
>
> - it makes it more straightforward to launch Tails with the default
> settings
> - it is coherent with GNOME 3 dialogs
>
Word. Having the top Greeter canvas frame as the 'Start Tails' button
location does fit GNOME 3, but so does having the bottom of the Greeter
canvas as the 'Start Tails' button location[1].
There is also the flow and the function logic to consider. The flow
logic is the order in which people will move through the experience.
Here, the 'Start Tails' button location would appropriately be the top
Greeter canvas frame, as the most occurrent use case is the collective
Default/Saved settings paths. The function logic is the intended
function, which, in this case, is the "check & go" experience. Here,
the 'Start Tails' button location would appropriately be at the bottom
of the Greeter canvas, as the "check & go" flow would end there.
Ditching the 'Close[x]' creates an imbalance of content within the top
of the Greeter canvas frame, as the only element remaining is the 'Start
Tails' button. However, a resolution to this, and an additional
resolution to the form of the Guided Configuration link, could be
placing both in the header like originally proposed, as buttons.
We should also consider, if we are to design for potential Tails
converts, that the placement of any non-meta actionable item in the
canvas frame will be confusing, as many people will be migrating from
Windows or Mac and might only expect a 'Close[x]', a 'Minimize[-]', and
a 'Fullscreen[<>]'.
Then there is the dialog type. Presentation Dialogs, which align with
the Greeter's function, suggest the bottom of the Greeter canvas as the
action bar location. Action Dialogs, which align to the Greeter's
context, suggest the top Greeter frame as the action bar 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
>>
>> Color Blocking
>> -----------------
>> Should the canvas either split into cells to emphasize separate
>> content
>> or stand-alone as a single-celled canvas?
>>
>> • Blocked
>> • Not Blocked
>>
>
> I have a little preference for the "Not blocked" as it looks
> more familiar to me and close the the GNOME 3 desktop, but I get the
> pros of the "Blocked" proposal.
>
Word. I like the intention behind the color blocking, but, in this
case, it feels like it adds to the clutter more than it lessens it. For
the most part, the GNOME 3 dialogs are clean and uncrowded, and so
should we be.
>>
>> 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? If miscellaneous, then two might be more
appropriate, as some of the 'Language' ones aren't an exact 'Language'
section fit and combining them all into one 'Settings' section could
organize this by reducing two miscellaneously grouped lists into one.
Two is also less, so it feels like two big decisions need made instead
of three - 'Storage' and 'Settings'. This gives us three macro-level
elements as the greeter:
• Storage
• Settings
• Start Tails
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.
If we do feel strongly about using three section labels, what is the
more appropriate name for '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.
>>
>> 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 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.
>>
>> Display/Hide
>> ---------------------
>> Should the Greeter use display/hide functionality to manage
>> information?
>>
>> • Accordion
>> • Drawer
>>
>
> I do not think that the greeter should use a display/hide
> functionality.
>
> If it had, then the "Drawer" would look a little less confusing to me.
>
Word. Many seem in favor of having no hidden content. This should
emphasize both trust and education.
>>
>> 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.
I do not recommend Option 2 for reasons touched on above - but feel free
to dig.
[3] Descriptive.Sentence.png
[4] GreeterSmall.png
>
> I have a strong opinion against the "Icon Buttons" and "Icon & Text
> Buttons" proposals as they complicate the flow of the greeter while
> having in my opinion few advantages oven the above.
>
Word. These are nice and minimal, but provide no check & go
functionality.
>>
>> Once we decide on these things we can bust out a mockup that embodies
>> the new decisions and we can hopefully move into each of the settings
>> options, e.g., Keyboard Language, and so on.
>>
Wordlife,
Spencer
