Hi,
Spencer <spencerone@???> wrote:
> >> 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?
>
OK for the 2nd for more beautiful spaces.
> >> 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.
>
I propose to drop the label for now, unless there is a value for it.
> >> 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.
>
Most of these concepts aren't present in the Tor Browser I think. You
icons looks unified with the GNOME desktop to me.
> >> 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.
>
Yes, but editing is a more common action than removing, so I think that
it would complicate the UX. Perhaps we can add a select mode, or add a
"Reset to defaults" button in the popover/dialog to edit each 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"
> >
>
> Yeah, I am being unfairly biased to the simplicity of single word
> labels, though 'Language & Region' is accurate.
>
Should we try with that?
> >> 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.
>
Do you want to create an icon that wouldn't be confused with the
locked/unlocked states?
> >> 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.
>
OK, unless we adopt the "Reset to defaults" approch for each setting as
proposed above.
> >> 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.
>
I don't think that we should change our mind on hiding the settings.
> >> 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.
>
OK
> >> 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 shortened text you are proposing are unfortunately not very
accurate technically... and I'm not sure we can do accurate *and* short.
> >>
> >> 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).
>
OK, so ve leave it as it was?
> >> 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?
>
Sort of, but encryption pass*phrases* must really be phrases, while
admin access with a pass*word* is OKish...
> >> 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).
>
OK
> >> 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.
>
The problem is that you propose a widget that, unless I'm mistaken,
doesn't exist in GTK. Have you found working examples?
> >> 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 :(
>
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."?
> >
>
> 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.
OK, even though I don't see the wording changes in the attachement.
> >> 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.
>
OK
> >>
> >> 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,
Yes.
> or would they each get
> their own? This is in addition to the 'Off' label, which you seem to be
> in support of :)
Cheers
