Hi,
spencerone@??? wrote:
> > Alan alan[at]boum.org:
> >> Spence spencerone[at]openmailbox.org:
> > it looks possible to refine your design to address most of
> > them. So I'm up for discussing it deeper. If feels a bit like going
> > back to another design iteration
>
> Is there a repository of previous design iterations?
>
Not really, but some are gathered at the end of the blueprint
(
https://tails.boum.org/blueprint/greeter_revamp_UI/).
> > Spencerone, is it possible to have an editable version of your mockups
> > so that I can propose modifications graphically?
> >
>
> Yes. Here[0].
>
Thanks!
> > - having to click an edit button to make setting editable looks useless
> > and painful to me. Consider a user that starts Tails for the 1st
> > time. She gets the defaults settings, and before editing anything,
> > she'll have to click an edit button. Why not to make the settings
> > editable straight form the summary screen
>
> This was considered. An example is in the working file found through the
> link shared above.
I propose we go this way as it saves one click without any drawback I
can think of. I think this is important to be friendly to new users
that have not yet any configuration.
> >
> > , e.g. with a Popover as on my current proposal[1]?
> >
>
> The popover makes sense, but the context it exists in in [1] does not.
> What is being suggested is eliminating a useless and painful click when
> one may not be needed, and this is agreeable. However, in [1], that
> isn't the case for advanced people who have to click the 'Advanced'
> button to configure their settings.
I think these is a misunderstanding here. Don't suggest to go back to
my split between Basic and Advanced settings but to have a popover as a
way to edit each option in your proposal (as a replacement of a common
edit button):
+-----------------------------------------------+
| Text language English |
+-----------------------------------------------+
__________/\__________
| Arabic |
| Cheenese |
| Deutsch |
| English |
| French |
+----------------------+
> What is suggested in this visual is having the Settings Display as the
> default on-load and having both use cases click once and chose their
> path, clearly and explicitly labeling this action as editing their
> configuration settings.
>
I hope we can find a way to be explicit that these are settings the one
can edit without adding this extra click. I even think that making a
save button once a setting is edited may be enough. That way:
- if the user changes a setting and don't click save, then it's just
changed for the next session
- if she clicks save, then these changes are saves.
> In the example pointed out above, one that resembles iOS, it was
> difficult to address the needs of the beginner and advanced use cases
> without exploring the hybrid flow shown in options B/C in a previous
> visual[2], where all use cases experience the same flow. The argument
> here was based on the occurrence of the use cases, where the beginners
> would only need the walkthrough in the beginning.
> It makes sense to
> tailor the experience to the most occurrent use case, the advanced, and
> since the beginners, the basic use case, have to click through each
> step, clicking to begin this shouldn't be an issue.
>
I do not think we should complicate thinks for beginners, as their 1st
use is when they get their impression about Tails.
> > That doesn't prevent us from showing a "Guided" button as on my
> > current proposal[1].
>
> 'Guided' is 'Basic', is it not?
No. I was referring to the "Discover: guided configuration" flow at the
left of the diagram in the blueprint.
> > If a setting is edited, we could then show a "Save" button.
> >
> > - I think that the Storage section should go above the Settings
> > section. A user that has an encrypted storage area indeed needs to
> > access this section at each boot.
> >
>
> True, and, though the Storage section is just a scroll away, presuming
> this dialogue is dimensionally fixed for all use cases, this is
> agreeable. The order options considered are:
>
> [If Settings is the appropriate label]
> - Alphabetical: Language, Settings, Storage
I think we should drop such an arbitrary ordering.
> - Importance: Storage, Language, Settings
To setup storage, one should select the right language first to be
able to type their passphrase.
> - Logical: Language, Storage, Settings
>
I think that makes much more sense.
> > - is there a good reason not to use icons as we have in current
> > proposal?
>
> No. The preference is toward less clutter and, although images [icons]
> are more communicatively universal, the decision was just to stick with
> words. There is room, visually and figuratively, especially since there
> was much work done on at least the Language icon.
>
I think we choose to use icons especially as this screen will often be
displayed in english to people that may not understand english as long
as they have not saved their localization settings (which they could
choose not to do to preserve their anonymity).
> > - we wanted to have direct access to the languages, thus the left
> > languages list in my current proposal [1]. Yours doesn't address that
> > currently.
> >
>
> The Language section is front and center. Unless Language is adjusted
> more often than not, having them be a click of an 'Edit' button away is
> not unreasonable.
>
> The weight placed on Text Language over the weight placed on the other
> three Language settings options felt imbalanced.
Why? The idea was that when an user selects a text language, the
other Language options are updated accordingly to reasonable defaults
for this language.
> > However, given the big number of languages we now support,
> > I'm not sure that this goal is still valid. It may very well be
> > better to have a dropdown (e.g. a Popover) with a search area.
> >
>
> Search was left out, but not for any logical reason. If the list is
> long, or people are just lazy, e.g., United States located towards the
> bottom of many lists, then a search field is appropriate.
>
This list is indeed very long.
> > Anyway please note that including the Persistence creation in the
> > greeter won't probably be
> > part of the 1st iteration of the revamp.
>
> No worries. Though, it seems most appropriate to do so. I do not know
> the difficulty involved with programming such changes, but, given that
> efforts will take the same amount of time, doing as much upfront
> potentially prevents added time and effort on the end. Though this
> overlooks any current deadlines we might be approaching.
>
We decided to go in 3 phases, so that we make actual progress we can
deliver to user as soon as it becomes reality:
- phase 1: redesign the greeter and implement "Basic" and "Advanced"
screen (which we might merge). We then have similar functionality
than the current greeter, but better presented.
- phase 2: add an assistant to guide beginners ("Discover: guided
configuration")
- phase 3: merge the persistence creation/configuration into the greeter
Cheers
