Hi,
Spencer <spencerone@???> wrote:
> > 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).
>
Thanks!
> 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.
>
I removed this title.
> 2. Explanation Paragraph
> -------------------------
> The spacing between the words is too great; could be less.
>
I can't do anything about that. Either we justify the text and it'll be
like that on some window sizes, or we just align it to the center/left
(which I don't find beautyful).
> 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.
>
I tightened them 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.
>
What is the expected UX to revert back to defaults? In an other email
it was suggested we could just drop this label.
> 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.
>
The icons are SVG files in the source. Feel free to propose
modifications (you can modify them on your computer, put it where the
old ones were, and see the result by launching the prototype again).
> 6. Information (Help) Icon
> ---------------------------
> The hover state adds a drop-shadow behind the icon; it should not, as it
> clouds the label.
>
I'll see how this can be fixed.
> 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).
>
The documentation won't be loaded in something that looks like a web
browser.
> 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,
Popover without arrows are not popovers, they are dialogs.
> can we do that instead?
Yes, but it adds one click to exit the dialog. I'm not convinced the
popovers are a bad idea... Should be discussed.
> 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.
>
In GNOME, a very similar panel of the control-center is called "Region
and Language"
> Stick with 'Language' for testing (though swapping to 'Locale' or
> 'Localization' is good, too).
Looks good to me.
> 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?
>
Yes, but it's not something that is easy to implement in the prototype
(plus it requires to have translations!)
> 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.
>
Makes sense, but all the other settings have an icon. Do we want an
icon for that setting too?
> 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.
>
OK
> 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.
>
So you think that we always display all the buttons, but make them
sensible of not depending (rather than displaying them or not)?
> 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.
>
What is "These"? It isn't clear to me.
> 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.
What you think about is not clear to me. Should we have a select mode?
We can also let the settings always selectable, but then it
conflicts with one-click edit.
>
> 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.
>
This comes form the GTK Theme, and changing it is generally not a good
idea. Couldn't we just let this text the same color as the setting name?
> Let's sentence-case the parenthetical text.
>
Does that mean an uppercase at the beginning of each sentence?
> 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.
>
I don't understand your proposal. Do you propose:
Administration Password
Enter a password to perform administrative tasks
Instead of:
Administration Password (Enter a password to perform administrative tasks)
> 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.
>
I don't understand.
> Hint text should be present when field is in focus; it disappears upon
> first character.
>
I don't think that this is possible. You can call it a bug in GTK.
> The hint text 'Type your desired passphrase' is preferable, as it
> clarifies that the passphrase in question does not yet exist.
OK, but I think that there we have a pass*word*, not a passphrase
(opposed as the encrypted storage)
> 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.
>
Please clarify the text you'd like to see in the verification box "Type
your password for verification"?
> 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.
>
Perhaps we just remove these labels?
> 16. Windows Camouflage
> -----------------------
> Descriptive text is spaced differently on the top line.
>
Again, it's not clear to me.
> 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.
>
OK
> 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.
>
OK
> 17. MAC Spoofing
> -----------------
> The label 'MAC Spoofing' is preferred for its simplicity and clarity;
> "addresses" isn't needed once "Windows" becomes "Desktop".
>
OK
> 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.
>
I don't agree. Without it, it's unclear that it can be better not to
spoof MAC Address. What about merging the two paragraphs with "This can
help to hide your geographical location, but might also raise
suspicion or cause network connection problems."?
> 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.
>
OK
> Resembling the other dialogs would also be a benefit. I am fiddling
> with this, too.
>
What about an introdution text (as the other dialogs) and the 3 buttons:
- connect directly to the Internet
- configure a bridge, firewall or proxy
- disable network
> What would the line item setting label read for the other options, e.g.,
> bridge, firewall, or proxy?
>
I don't understand.
> --------
>
> 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.
>
I think we need to test things now to know where to concentrate our
efforts, and what succeeds or fails in our designs. That doesn't
prevent us to polish our prototype a bit before!
> 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.
>
Please clarify the questions as soon as possible, and I'll try to
implement them.
Cheers
