<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">Hey Alex,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">I should say more explicitly: The new
design is beautiful. Thank you for the nice work.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">The below remarks are about details.
Important details. But...</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Your overall work is very nice
visually. Good work. Thank you.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<br>
<div class="moz-cite-prefix">Ben Bucksch wrote on 04.05.19 13:24:<br>
</div>
<blockquote type="cite"
cite="mid:f054bef1-a2be-e720-ed1c-6bcec13bb10e@beonex.com">
<div class="moz-cite-prefix">alex wrote on 02.05.19 08:40:<br>
</div>
<blockquote type="cite"
cite="mid:16ed7aed-221f-6da6-d195-af28ab8bec6b@thunderbird.net"><b>First
Screen</b>
<p>I created 2 variations which we could use for some A/B
testing. We could potentially release the version with a
smaller and less prominent "Get a New Email Address" first, to
later than replace it with a more prominent button once we
have those potential providers partnerships.</p>
</blockquote>
<p>As I stated before, I'd prefer not to put an intermediate form.
But if we absolutely have to have it, please use the second
version, which makes the common path more prominent and
decreases the important of "Get new email".</p>
<p>I think it's a fundamental mistake to adjust the UI to
partnership deals. Users notice that, it smells fishy, and it
decreases the UX. Usually, it does not work financially, either,
leading to ever more obnoxious presentation. You can see that
with internet ads right now. This is a development over years,
but it starts right here.<br>
</p>
<p>If you want to be a project for end users instead of for
financial income, you should make a decision right now what your
values are. You have enough donations.<br>
</p>
<p>I can only give my input as inventor, primary author and de
facto module owner of this dialog. But ultimately, that's a
collective project decision where you want to head and not mine.</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:16ed7aed-221f-6da6-d195-af28ab8bec6b@thunderbird.net">
<p>A tabbed system will be used to show the user the proper info
and fields of what they selected, and a "Other" option which
will open less common actions.</p>
</blockquote>
<p><br>
</p>
<p>I think that makes sense. Movemail should really be hidden.
There are probably about 4 users world-wide of this left today.
It probably doesn't work in practice anymore, due to anti-spam
measures. In fact, I would consider removing movemail entirely
and let those people use mutt.</p>
<p>I do like that this puts more prominence to Calendar and Chat
and RSS. It shows - in a very natural way - that Thunderbird can
do a lot more than just email.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:16ed7aed-221f-6da6-d195-af28ab8bec6b@thunderbird.net"><b>Error
messages</b>
<p>To increase consistency and get the user comfortable with our
paradigms, we should use the same notification style for
warnings and errors we're currently using in the upcoming TB
68.</p>
<p>Using the new notification system and color scheme will make
the messages feel more prominent and readable. We should also
make those messages selectable, so the user can copy the
errors for a web search.<br>
</p>
</blockquote>
<p><br>
</p>
<p>I like the colors on the mockups, yes. And the placement,
too.Good work.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:16ed7aed-221f-6da6-d195-af28ab8bec6b@thunderbird.net">
<p> </p>
<p><b>Manual Configuration</b></p>
<p>This is tricky since there are many fields and it's really
easy to overwhelm the user.</p>
<p>Splitting the "Incoming" and "Outgoing" fields in 2 tabs will
help us to visually streamline what the user needs to input,
and also will prevent the dialog to grow too much.<br>
With this UI, we can keep the maximum height of the modal
around 600px, which can fit on a 768px height laptop screen,
and will help us prevent annoying scrollbars.</p>
</blockquote>
<p><br>
</p>
<p>I understand your idea, but it is highly detrimental to UX to
hide things that the user might need. Tabs can make sense e.g.
in preferences dialogs, where the user wants to see only one at
a time.<br>
</p>
<p>In this case, the user will have to fill out <b>both </b>incoming
and outgoing sections. Furthermore, some fields (e.g. the
username) are connected. Hiding the outgoing section will likely
make many users think that if they filled out the Incoming
section, they can attempt a connection. They are wrong. That's
particularly bad, because the dialog only checks the incoming
server and not the outgoing server, so it may (worst case) leave
the user with a broken config.</p>
<p>If you need the user to fill out certain fields, you need to
*show* them the fields. In this case, it's not appropriate to
hide fields. They are all required.<br>
</p>
<p>50000 users per day go through this dialog. Even if it's 20%
who are confused, that's still several thousand per day.</p>
<p>Here, the fields are even identical, the descriptions are
identical. You have 2 columns right now in the grid, one for
label, one for fields. You just need to add a second column of
fields, so you only increase the size by about 60%, you do not
double it by adding outgoing as well. Moreover, you do not add
much mental burden, because the type of the fields is identical.</p>
<p>By hiding important fields, you are considerably reducing
usability instead of increasing it.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:16ed7aed-221f-6da6-d195-af28ab8bec6b@thunderbird.net">
<p>A potential "Get Help" button could be positioned if the
manual configuration is necessary, or if an error message is
particularly technical. For example, if the user gets a
firewall warning, or an SSL warning, we could set that button
to open a specific page in our website where we list common
errors and how to fix them.</p>
</blockquote>
<p><br>
</p>
<p>Makes sense.</p>
<p><br>
</p>
<p>One more thing: In the manual configuration mode of the dialog,
there needs to be the "Advanced Config" button. I know it's odd,
but it's needed for really fringe edge cases.</p>
<p>The manual configuration is not for end advanced end users.
It's for those users where we failed to find a working
configuration automatically, but these are still normal
non-techy users. They will need to gather the server name from
some configuration page of their company somewhere. And we help
them making this</p>
<ul>
<li>as comfortable as possible (by prefilling the correct ports,
authentication method etc.)</li>
<li>helping them getting it right (by validating the input and
checking that it works), and</li>
<li>making it as secure as possible (by using SSL when possible,
and making it easy to enable and test whether SSL works).</li>
</ul>
<p>The "Advanced Config" button is needed for really fringe edge
cases, like obscure required options, rare cases where our
validation fails due to a strange mail server, and people
wanting to set up the account while being offline. It doesn't
make much sense, but there have been multiple very angry
requests for that. This one button is the escape route for all
those edge cases. If we do not have this escape route, these
people will demand options for their specific case all over the
place, and each will have a good legitimate (even though rare)
reason for why they need it, and we'll have to discuss how to
accommodate them, one by one. If we were to remove "Advanced
Config", we would have endless discussions how to fulfill all
the different odd needs, and consequently destroy the normal
path. That would make nobody really happy, and waste time in
discussions (you have no idea how much time). By allowing this
simple escape route for advanced users, where we make absolutely
no checks, and the user can just mis-configure whatever he
wants, we make the power users and IT admins happy, without
compromising the normal path for normal end users.</p>
<p><br>
</p>
<p>I hope you see the idea behind the current dialog: Make as much
automatic as possible. Allow override where it fails. Do show
things that we absolutely need to get a working configuration,
and help as much as possible. Do not show things that are not
normally needed for most users, but allow this to be available
for those who do need it.<br>
</p>
<p>Ben<br>
</p>
</blockquote>
<p><br>
</p>
</body>
</html>