Hi,
>> Spence spencerone[at]openmailbox.org:
>> Attached is a visual exploration of what the Check & Go greeter screen
>> could look like.
>>
> Alan alan[at]boum.org:
> Thanks! Your proposals are much clearer to me with this drawing.
>>
>> In short, it attempts to consolidate as much of the existing flow
>> fragmentation as possible. There is a more detailed explanation on the
>> document itself.
>>
>> I hope it addresses the existing decisions as you intended, if not, we
>> can figure it out together :)
>>
> At first view, it seems to me that even though it doesn't address all
> the existing "decisions" (actually more directions or guidelines we
> agreed on)
>
Same thing. The intention is things collectively established.
>
> 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?
>
> to me but if we find a way to address
> tchou's and your concerns about the current proposed design then I
> think it's worth it.
>
> Spencerone, is it possible to have an editable version of your mockups
> so that I can propose modifications graphically?
>
Yes. Here[0].
>
> Please find below some detailed comment on the things I think we
> should modify/refine if we go that way:
>
> - it looks great overall.
>
: ) 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.
>
> , 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. Arguably, the advanced use case is
the most occurrent, as detailed in a previous message regarding use case
occurrences, and would need to be the default on-load, but that would
still make the basic person, the beginner, make this awful click. Either
way, one is being made to click.
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.
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.
>
> That doesn't prevent us from showing a "Guided" button as on my
> current proposal[1].
>
'Guided' is 'Basic', is it not? The blueprint only shows two alternate
flows, so it makes sense that Basic Configuration is the walkthrough for
the least occurrent use case: people who don't know what to do, yet.
>
> 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
- Importance: Storage, Language, Settings
- Logical: Language, Storage, Settings
If Storage is an administrative task, then the passphrase flows might be
combined here. But administrator setup was left out , as it was unclear
how that differed from the rest of the configuration privileges.
>
> - 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.
>
> - 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. Unless clicking on an
item in a right-aligned list of labels opened a larger left-aligned
dialogue, there was uncertainty with this hierarchy. The order seemed
fine, just not the compositional emphasis.
>
> 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.
>
> - I don't understand the "Specify the files that will be stored in the
> encrypted storage folder" part.
>
This is from the existing Persistence Wizard, where you specify the
files that would be saved to the persistant volume.
>
> 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.
Also, here are the use cases and their projected occurrences:
• Start Tails using Saved or Default settings [Most occurrent]
• Start Tails after Advanced Configuration [Commonly occurrent]
• Start Tails after Basic [Walkthrough] Configuration [Least occurrent]
[0]
http://buildingcoolshit.com/share
[1]
https://labs.riseup.net/code/attachments/download/650/greeter3.png
[2]
https://mailman.boum.org/pipermail/tails-ux/attachments/20150203/e5393651/attachment-0001.png
Wordlife,
SpencerOne
