Hi,
>>
>> Spencer:
>> 2. Explanation Paragraph
>> -------------------------
>> The spacing between the words is too great; could be less.
>>
>
> Alan:
> 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 beautiful).
>
I am all for:
----------
----------
----------
But maybe we can do:
----------
----------
------
Where only the last line does ragged right, what do you think?
>>
>> 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.
>
I am not certain on how to address this, but we could have the option to
reset to default where, and when, the "Custom" label appears (if we keep
it).
Otherwise, IDK. People can change the settings back to the default
settings one at a time but configuration will be detected and it will
not be recognized as default, and if it was, unless we are always
displaying "Default", it wouldn't be of much value.
>>
>> 5. Icons
>> ---------
>> Black seems a bit too dark; maybe we can find a suitable dark gray.
>>
>
> 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).
>
Will do. Unless someone has their heart set on helping with the icons,
it might be in our best interest to reach out to whomever does the logos
for the Tor Project to jazz up/aesthetically unify the icons we feel
best represent the intended concepts.
>>
>> 7. Popover Dialogs
>> -------------------
>> the way the popover dialogs function in 'Universal
>> Access' seems nice, 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.
>
Without this click we cannot select the items for removal. Editing can
be double click or long press for mobile, as is common in things like
spreadsheets.
>>
>> 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"
>
Yeah, I am being unfairly biased to the simplicity of single word
labels, though 'Language & Region' is accurate.
>>
>> 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!)
>
No worries :)
>> 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?
>
With that said, yes. We might be able to de-emphasize it.
>> 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)?
>
Yeah. I think it will make for a more clear, and therefore enjoyable,
experience.
>>
>> 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.
>
These = This; writing too much :P
>>
>> 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.
>
The .png in the other thread hopefully clarifies my thoughts on batch
adding setting types to the Check & Go screen.
It might have to conflict with one-click edit, or we need to rethink the
line items, as there is little room for a check box and they would need
removed (and I couldn't find any useful examples already in use by
GNOME). My goal was to avoid check boxes but I overlooked the
importance of one-click.
Or we rethink hiding the settings, though sajolida might not be happy
with us if we do this :) And there is no vertical space to do so no
matter what we do.
>>
>> 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?
>
No worries. The darker color might work well; contrast is all we are
going for.
>>
>> Let's sentence-case the parenthetical text.
>>
>
> Does that mean an uppercase at the beginning of each sentence?
>
Yeah. I am undecided here, though, as context drives this. Let's also
see about shortening the text to sound-byte sized concepts that clearly
support the label; whatever you think is nice.
>>
>> 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)
>
Yeah, but it didn't look so good (not very clear without significantly
more vertical space).
>>
>> 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)
>
Isn't the difference only in social security, where longer "phrases" are
more secure than "words" due to length?
>>
>> 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 word 'desired' holds all of the value, so, 'Type your desired
passphrase' would be nice, since it is likely new every time (or never).
>> 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?
>
I am not a fan of that look, but if it causes confusion...
The latest .png should have adjusted them enough, though other
suggestions are welcome.
>>
>> 16. Windows Camouflage
>> -----------------------
>> Descriptive text is spaced differently on the top line.
>>
>
> Again, it's not clear to me.
>
You addressed this at 2. above; I just worded it differently here :(
>>
>> 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."?
>
Adding "but might also raise suspicion or cause network connection
problems." to the end of the second sentence, as seen here [0], should
be great.
>>
>> 18. Network Configuration
>> --------------------------
>> Resembling the other dialogs would also be a benefit. I am fiddling
>> with this, too.
>>
>
> What about an introduction text (as the other dialogs) and the 3
> buttons:
>
> - connect directly to the Internet
> - configure a bridge, firewall or proxy
> - disable network
>
Good idea.
>>
>> What would the line item setting label read for the other options,
>> e.g.,
>> bridge, firewall, or proxy?
>>
>
> I don't understand.
>
'Network Configuration' state reads 'Direct' when connected directly to
the Tor network; what would the other setting states read? Would
bridge, firewall, and proxy all share one label, or would they each get
their own? This is in addition to the 'Off' label, which you seem to be
in support of :)
Wordlife,
Spencer
[0]:
https://mailman.boum.org/pipermail/tails-ux/attachments/20151029/62bcaff9/attachment-0001.png
