Hi,
>
> Alan:
> I just published a first prototype at
> http://repo.or.cz/tails-greeter-prototype.git
>
:) This is sweet (as is the entire Jess-based OS).
>
> Please review and report comments!
>
Though I risk commenting on things you are aware of, here are some
thoughts:
1. Action Bar
--------------
The dialog label is off-center (for obvious spacing reasons), so maybe
we remove it. "Welcome" is a greeting and therefore establishes that
this is the Greeter, if such an establishment is valuable to people.
2. Explanation Paragraph
-------------------------
The spacing between the words is too great; could be less.
3. Section Labels
------------------
The elements that make up the section label strings are spaced a bit too
far apart. It seems like gtk auto spacing, and therefore makes sense,
but maybe we can tighten it up a bit.
4. Default/Custom Settings Label
---------------------------------
There is no way to revert back to 'Default'; there should be. 'Privacy
Settings' sandboxes this, maybe this makes sense.
5. Icons
---------
Black seems a bit too dark; maybe we can find a suitable dark gray. The
calendar icon has some extra white. There are some other thoughts but I
have to look into GNOME icons more first.
6. Information (Help) Icon
---------------------------
The hover state adds a drop-shadow behind the icon; it should not, as it
clouds the label.
If it loads local content *in* the browser, we should restrict that to a
text file or something more clear; feels like launching the internet
since Tor has to be ready (ignore this out-of-scope comment if you
like).
7. Popover Dialogs
-------------------
The popover dialog with the arrows is not as clear as the popover dialog
without the arrows; the way the popover dialogs function in 'Universal
Access' seems nice, can we do that instead? It isolates the task very
clearly and supports the experience logic of "One thing at a time.",
since that is how our brains seem to function.
8. Language Section
--------------------
The 'Language' label is more accurate than 'Region' or 'Localization',
as text, keyboard, and formats are based on the preferred language of
each person. 'Time Zone' does differ in this sense and maybe, since
languages aren't defined by region, we can say all of this is driven by
the locale of each person; Tails personal locale, if you will.
Stick with 'Language' for testing (though swapping to 'Locale' or
'Localization' is good, too). We could also do an AB test with this
where some groups get a different label for this section; 'Localization'
is a good competitor for this testing.
9. Text Language Setting
-------------------------
Greeter should update based on each customization, right?
10. Encrypted Storage Section
------------------------------
The lock icon seems misleading here (during configuration). Maybe we
don't load it unless encrypted persistence is configured. The lock and
unlocked states of the padlock icon would only accompany the lock and
unlocked button states.
11. Time Zone Setting
----------------------
I overlooked the ticket regarding a map intentionally, so as to align
with the Greeter Design Phases. However, it was deeply considered so
its possible future implementation wouldn't break the rest of the
Greeter. We could leave it as-is for testing.
12. Privacy Settings Add/Remove Buttons
----------------------------------------
The minus button to remove settings is needed when no setting is
present, as it is present in other similarly functioning dialogs, such
as 'Online Accounts'. The plus button to add settings is also needed
when all settings have been added, as it should mirror the function of
the minus button. We should show the buttons for testing.
UI is brain networking, in that, like computer networking, each bit adds
to latency and consumption of resources. So the presence of the
opposite state is needed, even when it is not, as it removes the load on
each user having to gestalt their way to knowing that if there is a plus
button to add settings, then somewhere there must be a minus button to
remove settings.
13. Privacy Settings Add/Remove Function
-----------------------------------------
The 'Select a setting type' dialog would benefit from the ability to
batch add items, as clicking in and out each time becomes tiresome.
This would include an 'Add' and 'Cancel' button; basically combining
what was and what is.
This breaks some stuff so I will fiddle with this now but don't wait on
me. Though we should have these changed for testing.
Removing items isn't pleasant, as earlier settings are blocked by more
recent ones. Batch adding should support specified removal, since they
require a similar selector to function.
14. Privacy Settings Labels
----------------------------
The blue selected state isn't contrasted enough against the
parenthetical text; gray is no good. 50% white is preferred but your
eye will be the best judge.
Let's sentence-case the parenthetical text.
The parenthetical text might look, and therefore read, better underneath
the label. Keep the same spacing around the text. Maybe drop the
parenthesis to be more clear.
Keep 'Save Privacy Settings' check box and test it so we don't guess at
it too much longer. The more data the better :)
15. Administrative Account
---------------------------
Descriptive text is spaced differently on the top line.
Hint text should be present when field is in focus; it disappears upon
first character.
The hint text 'Type your desired passphrase' is preferable, as it
clarifies that the passphrase in question does not yet exist. This is
not the case with 'Type your passphrase', which requires "for
verification" in the next field to clarify (with quite a leap) that this
is a new passphrase that needs created now.
The buttons in the fields were intended to be emphasis, so do what you
can to make that the case. The intention is to have the field centered
in the dialog; left floating labels offsets that in an undesirable way
and make things less clear.
16. Windows Camouflage
-----------------------
Descriptive text is spaced differently on the top line.
The label 'Desktop Camouflage' is preferred, as it is the underlining
(most reduced) function of this feature. Also, supporting Macs suggests
the possibility of more functional camouflage options in the future.
Test in either state. AB testing can also be done here.
Removing "Activate" would make the switch seem more fitting as a
follow-up to the text 'Microsoft Windows 10 Camouflage'. "Activate"
implies a question and is soliciting a response that 'On/Off' doesn't
provide.
17. MAC Spoofing
-----------------
The label 'MAC Spoofing' is preferred for its simplicity and clarity;
"addresses" isn't needed once "Windows" becomes "Desktop".
The second paragraph isn't needed; 'Help' might be the appropriate
destination in this case, as the warning requires further investigation
that breaks the flow.
Bottom spacing is needed but would be addressed by the removal of the
second paragraph.
18. Network Configuration
--------------------------
This setting would benefit from a third 'Off' function.
Resembling the other dialogs would also be a benefit. I am fiddling
with this, too.
What would the line item setting label read for the other options, e.g.,
bridge, firewall, or proxy?
--------
--------
If I commented on it but didn't offer a resolution, then the issues are
still swimming around in my head; if any are suitable they will make an
appearance.
If I didn't comment on it at all, then I absolutely support it!
Everything needs addressed before testing so we know what to test.
Testing should happen after all adjustments so as to also make the
testing session as fruitful as possible.
Short-term = Supported by logic
Long-term = Supported by (needs) testing
Short-term: 1, 2, 3, 4, 5, 6, 9, 10, 14, 15, 16, 17, & 18
Long-term: 7, 8, 11, 12, & 13
Let me know if there is any way to make this easier on, or more
enjoyable for, you.
Wordlife,
Spencer
