Hi,
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...
> 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.
> 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.
> 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
> 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?
> 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
- 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.
Cheers
%0A>%20-%20Feedback%20to%20the%20user%20which%20options%20are%20going%20to%20be%20used%20(#8974)%0A>%20%0A>%20>%20I%20think%20that%20core%20problem%20that%20we%20need%20to%20solve%20here%20is%20to%20find%20the%0A>%20>%20technical%20means%20of%20doing%20this:%20having%20these%20options%20available%20but%20not%0A>%20>%20displayed%20by%20default.%20The%20two%20different%20paths%20%5B1%5D%20were%20maybe%20to%20right,%0A>%20>%20the%20accordion%20%5B2%5D%20was%20maybe%20not%20realistic,%20but%20we%20also%20tried%20views%20and%0A>%20>%20tabs%20%5B3%5D.%0A>%20>%20%0A>%20>%20%5B3%5D:%20https://labs.riseup.net/code/attachments/download/652/greeter2.png%0A>%20>%20%0A>%20About%20the%20concerns%20raised%20in%20the%20message%20you%20link:%0A>%20%0A>%20-%20%22It%20adds%20more%20information%20than%20need%20to%20newcomers,%20while%20we%20are%0A>%20%20%20working%20hard%20to%20making%20the%20default%20options%20not%20harmful%20in%20the%20general%0A>%20%20%20case.%22:%20yes,%20but%20we%20added%20a%20sentence%20that%20default%20settings%20are%20safest%0A>%20%20%20in%20most%20situations%0A>%20%0A>%20-%20%22Advanced%20options%20might%20grow%20bigger%20in%20the%20future,%20and%20we%20might%20then%0A>%20%20%20have%20problems%20showing%20everything%20on%20a%20single%20screen.%22:%20more%20options%0A>%20%20%20would%20fit%20in%20most%20screens,%20and%20we%20already%20have%20a%20scrollbar%20if%0A>%20%20%20required.%20The%20only%20things%20that%20would%20need%20scrolling%20would%20be%20these%0A>%20%20%20advanced%20options.%0A>%20%0A>%20>%20We%20need%20to%20get%20back%20to%20this%20discussion%20and%20find%20solutions%20to%20this%0A>%20>%20problem%20that%20takes%20into%20accounts%20all%20the%20arguments%20that%20were%20provided%0A>%20>%20already%20and%20works%20with%20the%20GNOME%20toolkit.%0A>%20>%20%0A>%20Please%20note%20that%20this%20question%20was%20the%206th%20in%20the%20very%20clear%20email%0A>%20from%20spencerone%20about%20needed%20decisions%20that%20nobody%20but%20me%20answered,%20so%20I%0A>%20find%20a%20but%20annoying%20that%20we%20discuss%20that%20again%20now:%0A>%20%0A>%20https://mailman.boum.org/pipermail/tails-ux/2015-June/000513.html%0A>%20https://mailman.boum.org/pipermail/tails-ux/attachments/20150623/ae446132/attachment-0001.pdf%0A>%20%0A>%20>%20But%20once%20we%20have%20this,%20I'm%20very%20confident%20that%20we%20can%20continue%0A>%20>%20building%20up%20on%20the%20more%20detailed%20work%20that%20you%20have%20been%20doing%20so%20far%0A>%20>%20as%20it's%20great%20and%20then%20the%20final%20result%20will%20be%20rock%20solid!%0A>%20>%20%0A>%20If%20we%20really%20don't%20agree%20about%20the%20current%20proposal%20(which%20I%20really%0A>%20think%20is%20the%20best),%20we%20can%20%0A>%20%0A>%20-%20add%20some%20kind%20of%20drawer%20as%20described%20in%20the%20above%20mentioned%20email%0A>%20%20%20in%20question%206,%20that%20would%20be%20only%20for%20privacy%20settings%0A>%20%0A>%20-%20always%20display%20settings%20that%20diverge%20from%20defaults%20to%20%22Feedback%20to%0A>%20%20%20the%20user%20which%20options%20are%20going%20to%20be%20used%22%20(#8974).%0A>%20%0A>%20The%20drawbacks%20of%20this%20would%20be%20that%20is%20conflicts%20with%20one%20of%20our%20goals%0A>%20that%20were%20discoverability%20of%20the%20interface,%20that%20was%20one%20of%20the%0A>%20criteria%20that%20spencerone%20has%20to%20judge%20if%20an%20interface%20is%20good.%0A>%20%0A>%20>%20Also%20keep%20in%20mind%20that%20**none**%20of%20these%20mockups%20were%20tested%20with%0A>%20>%20users%20yet.%20We%20talked%20about%20them%20amongst%20ourselves,%20we%20reviewed%20it%20with%0A>%20>%20experts,%20etc.%20but%20we%20never%20sat%20with%20regular%20users%20and%20watch%20them%0A>%20>%20interact%20with%20those.%0A>%20>%20%0A>%20Didn't%20tchou%20do%20that%20for%20the%20iteration%20before%20its%20proposal?%0A>%20%0A>%20>%20My%20personal%20take%20on%20this%20is%20that%20we%20should%20take%20it%20easy,%20come%20up%20with%0A>%20>%20something%20that's%20simple,%20classic,%20as%20little%20controversial%20as%20possible,%0A>%20>%20and%20easy%20to%20implement.%20Then%20test%20it%20and%20see%20how%20it%20does.%20I%20would%20also%0A>%20>%20be%20in%20favor%20of%20testing%20stuff%20on%20paper%20first%20but%20I%20feel%20like%20Alan%20is%0A>%20>%20dying%20to%20type%20some%20code;%20which%20is%20great!%0A>%20>%20%0A>%20I'm%20not%20against%20it,%20but:%0A>%20%0A>%20-%20I%20start%20to%20be%20tired%20of%20waiting%20and%20discussing%20again%20and%20again%20on%0A>%20%20%20details%0A>%20-%20we%20refine%20things%20since%20already%20more%20than%20one%20year,%20had%20already%20at%0A>%20%20%20least%20two%20proposals%20that%20were%20nearly%20validated%20then%20changed%20again%0A>%20-%20I'm%20convinced%20that%20all%20our%20current%20proposals%20are%20way%20better%20than%20what%0A>%20%20%20we%20currently%20have,%20even%20though%20they%20may%20not%20be%20perfect%0A>%20%0A>%20So%20I%20don't%20want%20to%20wait%20again%20for%20months,%20which%20doesn't%20prevent%20anybody%0A>%20to%20organize%20a%20paper%20test%20session%20timely.%0A>%20%0A>%20Cheers%0A>%20%0A>%20 "Reply to this message")
