Hi, all thanks a lot for the feedback. That's very valuable feedback. Let me answer some feedback using Olavs email.
Am 07.06.2014 21:06, Olav Seyfarth schrieb/wrote:
> is it necessary to be able to reset to defaults? It complicates things...
>
Well, it's not a reset to the defaults;
it is a reset to the state an email would have without
having enabled the "finally forcing to sign/enc or not to sign/enc"
(therefore "use defaults and rules").
This reset is e.g. useful if I force encryption but then want to decide
to add other recipients and to see which state rules give.
As this is not the common case, it is not provided via the status bar icons.
But we could easily make it an advanced menu item.
> What's a default for in that situation (composing a new message)? In my
> opinion:
> just to have a decent initial state. Nothing more. After sending, that what
> was
> changed is irrelevant.
>
after sending everything is irrelevant.
I am talking about the compose menu.
> Another thing that put me off: what IS the default? I use many accounts and to
> not recall on every account which settings I currently employ. Good UI design
> must enable the user to know what to expect from an action like "use default".
> _____
>
Note again I wrote "default & rules":
That implies now:
- initial default
- enc/sign cause due to a reply to an enc/sign email
- processed recipient rules
- auto encryption
- rule to sign if (not) encrypted
That's a lot, but probably nobody wants to disable any of these features.
The resulting UI is the best I found to deal with that.
(with the help of Patrick I reversed engineered, which option
might cause which effect, and the situation is not easy to understand;
I can send you a excel sheet if you are interested).
> I propose to distinguish between standard (rename to "simple?) and expert
> view:
>
>
> *1* Simple view
>
> All is set to fully automatic (opportunistic encryption without interaction)
> and
> that default cannot be modified (in standard view only).
>
The new default for the ordinary user will be:
- enc off
- auto encrypt if keys valid
This is so simple and easy to use so that I bet that 90% of users
will use this mode.
And usually even experts need no or only a few rules.
But something must always be possible:
Finally manually force to encrypt/sign or not to encrypt/sign.
This is nothing we can skip in any mode.
This is feedback I got already from people trying out the new features
(and BTW, this is also what GPGTools provides for Apple).
> To allow exceptions, the user may use the icons or menu. Three entries there:
>
> Sign message [tick indicates current state]
> Encrypt message [tick indicates current state]
> Switch to expert settings
> ----------------------------------------------
>
As I wrote, IMO that's definitely not enough.
Even beginners always have to be able to disable encryption explicitly
if it is automatically selected.
The rest is more or less what I programmed
without the ability to switch to expert mode
(we already have basic and expert mode, we don't need
one more confusion; as I wrote if it is useful,
we can make "rest to default&rules" an expert mode entry).
> Note: no PGP/MIME menu entry to switch it. A common user doesn't want to know
> what PGP/MIME is. I'd even go as far as to enable HTML (since it's TB default)
> and PGP/MIME in simple view.
>
As I wrote, this is disabled in the non-expert mode now.
But you are right, whether PGP/mime should be default and whether HTML
should be enabled by default is indeed something we should discuss.
> *2* Expert view
>
> The user may control everything as before / as you want to change it if it's
> OK with Patrick.
>
Of course, this is still possible, but with a lot of clean-ups.
For example: In the past the option to sign if (not) encrypted
was applied after the default but before the rules.
Thus, if a rule force encryption signing was not forced although
forcing to sign was set. Very confusing.
Now, there is a much cleaner model:
a) use account specific defaults
b) process rule to force answering in the mode of the mail you reply to
c) use auto encryption if selected and all keys valid
d) process rules (first feature that might force not to sign/encrypt!)
e) process final setting (final interactive directions, includes
options to "sign if (not) encrypt")
Steps a) to d) count as "defaults and rules"
Step e) is what you can force with the icon buttons and menu items
> That said, I think that we should discuss severe changes within the team
> first,
> then ask the list for feedback, rediscuss internally and then implement it.
In general I strongly agree, BUT
a couple of thoughts/notes about this:
- I did discuss all changes with Patrick, directly.
So, he knows.
- One problem is that what you propose takes too long.
It not only required fast feedback it also required
the need to explain everything in ahead.
Therefore, I only ask if I really need directions or help.
- Any theoretical discussion about a good UI is always
not more than theory.
I have made so many iterations now, which I didn't discuss
with you, because when I EXPERIENCED it it turned out
to be bad or having some flaws.
Thus, you have to "look&feel" a UI to see whether it works.
Thus, we need a highly iterative approach.
You will be able to try things out on the master pretty soon
(ideally on Tuesday).
Just in case:
Branch ForceSignEnc contains my current version.
- We have no time.
We have to fix the biggest UI flaws very quick
because what we really ASAP need is a useful UI for the
average non-expert user, because the current UI is is what
frustrates people now unnecessarily a lot.
Therefore, I program day-by-day with huge amount of time and effort
now to finally be able to give enigmail to others so that they just say:
Wow, I never thought it's so easy and convenient to sign&encrypt.
BUT: If I really go into the wrong overall direction,
THEN we should discuss that.
If not, please allow me to chose that mode
for fast necessary improvements.
> That way, there is no work done in vain and we need some time to think over
> propositions and have the chance to speak up.
>
You always have a chance through the nightly builds.
This change is special because it requires many modifications
and try&error's,
which is why the whole stuff is first programmed in a sub-branch.
Note also that even if the UI does not fit,
the work is usually not waste.
More than 80% is just refactoring so that the code becomes
maintainable and easy to understand and verify.
Changing whether one menu item is enabled or not
and whether a button toggles or forces encryption
is now a very small change.
> Just my 2ct,
Thanks a lot again.
You should really be able to experience the new look&feel.
I showed it at a conference in Oslo last week in front
of 40 people.
They really liked it (and found stuff to improve).
If you can't do it yourself,
I am happy to provide a xpi file to test it, now.
Best
Nico
--
Nicolai M. Josuttis
www.josuttis.de
signature.asc
Description: OpenPGP digital signature
_______________________________________________ enigmail-users mailing list [email protected] https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
