<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Wow, this is a great and thorough message which made the whole
conversation and reasoning way more clear than before. Thank you
so much for this.<br>
</p>
<blockquote type="cite"
cite="mid:d00c8edd-5e1b-2b6f-bfe9-19f7f5584f38@beonex.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div class="moz-cite-prefix">First off: I'm not against keeping
the current "Get a new email address" button in the "Account
creation dialog", as long as it stays no more prominent than it
is. I think any more prominent would not be in the users'
interest.<br>
</div>
</blockquote>
<p>Sure, I think that'd be a good compromise. If data and previous
experience guide us to not put any emphasis on that secondary CTA,
we can reduce predominance and keep the focus on using an existing
account.</p>
<blockquote type="cite"
cite="mid:d00c8edd-5e1b-2b6f-bfe9-19f7f5584f38@beonex.com">
<p>If you want to improve the styling, go ahead. </p>
</blockquote>
<p>I'm glad we're on the same page with this :D<br>
</p>
<blockquote type="cite"
cite="mid:d00c8edd-5e1b-2b6f-bfe9-19f7f5584f38@beonex.com">
<p>What I was referring to was user experience (UX), meaning: Is
the user lost? ... So, what is on the screen and what is not, I
would say that's very good. The styling is horrendous, I would
concur. </p>
</blockquote>
<p>It's not just a matter of styling. I think there are some UX
issues with the current dialog. The most obvious one is the fact
that, based on which messages are displayed, the dialog changes
size, changing location of fields and buttons.</p>
<p>Another big issue I found is the fact that if, halfway through
setting an existing account, the user decides to click on "Get a
new email address" to see if that's the correct path to go,
closing that secondary dialog resets the previously inputted
account info and closes the original dialog.</p>
<p>That's why I'd like to implement a sort of "first screen" where
the user can decide which path to go, removing the potential
accident of clicking the "get a new email" button out of curiosity
and accidentally disrupt the setup experience (I did that
accidentally because I was curious >_>)<br>
</p>
<blockquote type="cite"
cite="mid:d00c8edd-5e1b-2b6f-bfe9-19f7f5584f38@beonex.com">
<p>Mark suggested to make the error tooltip appear without hover.
I think that would be an acceptable compromise for the above 3
fields. The errors there are not coming from the server and
rather obvious... Making server errors less prominent would lead
to huge UX problems and cause endless pain to end users.)</p>
</blockquote>
I totally agree with you on this. The tooltips can be used to
streamline minor warnings and client-side errors. Server-side errors
must be prominent, easily readable, properly communicate the warning
level of the error, and be permanent until the issue has been
resolved.<br>
<blockquote type="cite"
cite="mid:d00c8edd-5e1b-2b6f-bfe9-19f7f5584f38@beonex.com">
<p>If you can make it more beautiful, without changing the logic
(removing or adding stuff), then I think the result will be very
positive. I for one would be very happy about it.</p>
</blockquote>
<p>That's the goal! The logic works but it looks awful, and users
can negatively react to the outdated UI, affecting their
perception of TB.<br>
</p>
<p>Thank you again for your detailed answer. I will update the
mock-ups to reflect these suggestions, as well as adding example
screens for server-side errors and manual configuration.</p>
<p>Cheers,<br>
</p>
<div class="moz-signature">-- <br>
<span style="color:#666;font-family:mono; font-size:small"><b>Alessandro
Castellani</b><br>
Lead UX Architect<br>
Thunderbird</span></div>
</body>
</html>