Alan:
> On Tue, 11 Aug 2015 17:38:32 +0000
> sajolida <sajolida@???> wrote:
>> First of all, I owe you a disclaimer.
>
> Me too: I start to be tired of discussing again and again the same
> things each time someone jumps in the discussion again. I'm sure we all
> want to make things better, but I'm loosing patience...
Same here. But many times throughout this process I had the feeling that
we were spending more time *questioning* the good stuff we already had
than trying to *build upon* it. That's when things get discussed again
and again (for example here about displaying all options upfront or not).
And that's especially true over email. This introduces tons of delay,
lengthy thread that very few people read (and we can't really blame them
for that). That's why I personally tend to give more importance to the
decisions and designs that were made face-to-face and with as many
people involved as possible. And not just a few people down in a lengthy
thread.
I personally felt like I was being the conservative one here, holding
back to past agreements and not changing stuff too much. I really think
we need less ideas, less debates, and more testing.
>> I've been partly on holidays
>> since you started this thread, now I'm back on tracks but it took me a
>> while to find the time to go through it. It was an hour of reading!
>>
> We're currently working on a summary of our proposal:
> https://tails.boum.org/blueprint/greeter_revamp_UI/design_rationale_phase1/
>
>> Shortly afterwards we started an interesting discussion to try to
>> isolate the problem behind #8976:
>>
>> https://mailman.boum.org/pipermail/tails-ux/2015-March/000309.html
>>
>> Please have a good read at it again as many good arguments were give
>> there already. Long story short, at least intrigeri, Alan, and me
>> expressed themselves again displaying all options by default on the
>> first screen. I understand that tchou's position is similar since he
>> was still hiding them with his accordion.
>
> I personally changed my mind a bit when I realized that several
> people that were into design did prefer merging 1st screen and advanced
> options.
Well... I can tell you about at least 4 people that are into design and
that disagree with you: two at NUMA and two in the Tails UX team :)
>> To me, no strong enough evidence against this collective stand was
>> raised in this thread. And I'm thus surprised to see that this was not
>> taken into account by these designs: all options are displayed upfront
>> by default.
>
> Our current proposal addresses:
>
> - Consider merging "basic" and "advanced" screens (#8976)
> - Feedback to the user which options are going to be used (#8974)
>
>> I think that core problem that we need to solve here is to find the
>> technical means of doing this: having these options available but not
>> displayed by default. The two different paths [1] were maybe to right,
>> the accordion [2] was maybe not realistic, but we also tried views and
>> tabs [3].
>>
>> [3]: https://labs.riseup.net/code/attachments/download/652/greeter2.png
>>
> About the concerns raised in the message you link:
>
> - "It adds more information than need to newcomers, while we are
> working hard to making the default options not harmful in the general
> case.": yes, but we added a sentence that default settings are safest
> in most situations
>
> - "Advanced options might grow bigger in the future, and we might then
> have problems showing everything on a single screen.": more options
> would fit in most screens, and we already have a scrollbar if
> required. The only things that would need scrolling would be these
> advanced options.
I'm tempted to go jump into this discussion again, add my thoughts to
your summary of pros and cons but I'll refrain from doing that unless
you everybody here is interested in having this discussion again and
more people get involved (at least tchou and intrigeri).
>> We need to get back to this discussion and find solutions to this
>> problem that takes into accounts all the arguments that were provided
>> already and works with the GNOME toolkit.
>>
> Please note that this question was the 6th in the very clear email
> from spencerone about needed decisions that nobody but me answered, so I
> find a but annoying that we discuss that again now:
>
> https://mailman.boum.org/pipermail/tails-ux/2015-June/000513.html
> https://mailman.boum.org/pipermail/tails-ux/attachments/20150623/ae446132/attachment-0001.pdf
I was traveling from June 24 to August 1. The thread pilled up and I
answer on August 11. I agree that was very late but you were not the
only one to answer.
>> But once we have this, I'm very confident that we can continue
>> building up on the more detailed work that you have been doing so far
>> as it's great and then the final result will be rock solid!
>>
> If we really don't agree about the current proposal (which I really
> think is the best), we can
>
> - add some kind of drawer as described in the above mentioned email
> in question 6, that would be only for privacy settings
>
> - always display settings that diverge from defaults to "Feedback to
> the user which options are going to be used" (#8974).
>
> The drawbacks of this would be that is conflicts with one of our goals
> that were discoverability of the interface, that was one of the
> criteria that spencerone has to judge if an interface is good.
>
>> Also keep in mind that **none** of these mockups were tested with
>> users yet. We talked about them amongst ourselves, we reviewed it with
>> experts, etc. but we never sat with regular users and watch them
>> interact with those.
>
> Didn't tchou do that for the iteration before its proposal?
Nope. He reviewed it with experts which is quite different. See our
misunderstanding on #8233#9 and #8233#10.
>> My personal take on this is that we should take it easy, come up with
>> something that's simple, classic, as little controversial as possible,
>> and easy to implement. Then test it and see how it does. I would also
>> be in favor of testing stuff on paper first but I feel like Alan is
>> dying to type some code; which is great!
>>
> I'm not against it, but:
>
> - I start to be tired of waiting and discussing again and again on
> details
> - we refine things since already more than one year, had already at
> least two proposals that were nearly validated then changed again
Personally I've seen more "questioning" than "refining".
> - I'm convinced that all our current proposals are way better than what
> we currently have, even though they may not be perfect
>
> So I don't want to wait again for months, which doesn't prevent anybody
> to organize a paper test session timely.
Fine with me. I understand your frustration of not having something to
implement yet and I would be super happy if you jumped to the code right
now and come up with a prototype of whatever you prefer.
But I'm not considering releasing any code that hasn't got through
serious user testing, either on paper or on real users, and with you
attending the testing sessions. We've been through the UX process with
NUMA from 1.5 year and, as I explained earlier, no proposal was ever
tested with users, on top of that the current proposal breaks some
fundamental assumptions of the work that was done at NUMA (displaying
everything upfront) so to me, we can't validate it only by discussing
over email.
Paper testing is useful as it can be faster to put into practice and
helps validating the design before writing the code. But again, if you
want to come up with a prototype to test on computers first, that's fine
with me as long as you take into account that stuff might change as a
consequence of testing.
If you're ready to do that, I'm fine with implementing whatever solution
you currently prefer. Then, let's also schedule a user testing session.
