Hey,
>>> Alan alan[at]boum.org:
>>> 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
>>>
>> SpencerOne spencerone[at]openmailbox.org:
>> 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.
>
Okay. The visuals and these last comments were made with the
understanding that we were keeping the split between a Basic and
Advanced configuration flow, but that the Basic was a guided
walkthrough. I am all for the hybrid configuration being the flow for
all cases. One interface to rule them all :)
>>>
>>> e.g. with a Popover as on my current proposal[0]?
>>>
>>
>> The popover makes sense, but the context it exists in in [0] 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 [0], that
>> isn't the case for advanced people who have to click the 'Advanced'
>> button to configure their settings.
>>
>
> I think there 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):
>
Definitely a misunderstanding, as addressed above. However, with the
popover, can it be a whole screen pop-over, like iOS, or is there
collective preference with staying within the same localized canvas
space? With the whole screen pop-over, an activated 'Save' button's
function is much more clear, as it addresses one setting type. This is
in contrast to an activated 'Save' button that addresses multiple
settings edits, though is much less laborious with no back and forth.
>
> +-----------------------------------------------+
> | Text language English |
> +-----------------------------------------------+
> __________/\__________
> | Arabic |
> | Chinese |
> | Deutsch |
> | English |
> | French |
> +----------------------+
>
ASCII UI. :D
>>
>> 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 saved.
>
Yes, this is enough, but comes after the fact, requiring editability to
be discovered. An instruction text could address this. Also, some sort
of arrow, like the one that signifies a pop-over, could work. The
question we might still need to address is, if we go with a popover, how
can this be communicated if, for example, we don't use some sort of
instruction text.
>>
>> 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[1], 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.
>
But isn't having the same hybridized configuration flow arguably doing
this? Or are we just going to make the interface that much more clear?
>>>
>>> That doesn't prevent us from showing a "Guided" button as on my
>>> current proposal[0].
>>>
>>
>> '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.
>
Yes, this has been clear. But since it isn't addressed in the blueprint
other than existing as a button, it has been presumed that it would just
be the same as the Basic Configuration flow but include detailed
instruction text, which is why the visuals have been labeling this as
Basic Configuration [Walkthrough]. Maybe the suggestion to merge Basic
and Advanced isn't what I have been imagining. To me the screens titled
Introduction, Context, and Check & Go were part of the Basic
Configuration flow, with the Advanced Configuration flow only having the
one dialog screen. In the Basic Configuration flow these isolated
screens are the same as the section in the Advanced Configuration flow
screen but with more detailed instruction, as it walks newer users
through the settings in a less technical manner, e.g., "Where will you
be using Tails: Home, Cafe, etc.", vs allowing the more technical
configuration like 'MAC Address Spoofing', and so on.
>>
>> Logical Ordering: Language, Storage, Settings
>>
> I think that makes much more sense.
>
Agreed. And this is what you currently have, though in a slightly
different form.
>>>
>>> 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).
>
Agreed. Images communicate across language barriers.
>>>
>>> we wanted to have direct access to the languages, thus the left
>>> languages list in my current proposal [0]. 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.
>
Okay. I was unaware of the auto-update feature. Though this forces a
particular order, the emphasis might be suggestive enough to people so
they don't edit in the wrong order, having defaults overwrite their
edits. However, even with the auto-update, the compositional balance
could be improved, especially given the limited area and growing
language list.
Also, isn't there much more to 'Formats' than selecting a country? This
would need some more dedicated space, that maybe can't be supported by a
popover, making a whole screen pop-over for all 'Language' somewhat
appropriate.
>>>
>>> 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
>
Cool, but if #2 requires changes to #1, and #3 requires changes to
#2, then it will be more effort and time overall. #3 might not be an
issue, but given the possible miscommunication of Basic/Guided and
Advanced configurations, it could become difficult. Though I am down
for whatever schedule already in place.
[0]
https://labs.riseup.net/code/attachments/download/650/greeter3.png
[1]
https://mailman.boum.org/pipermail/tails-ux/attachments/20150203/e5393651/attachment-0001.png
[2]
https://mailman.boum.org/pipermail/tails-ux/attachments/20150204/9350265d/attachment-0001.png
Wordlife,
SpencerOne
