<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<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>
</body>
</html>