UI mock-up - Account Setup

Alessandro Castellani alessandro at thunderbird.net
Tue Apr 30 23:03:11 UTC 2019

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.

> 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.

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.

> If you want to improve the styling, go ahead.
I'm glad we're on the same page with this :D

> 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.
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.

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.

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 >_>)

> 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.)
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.
> 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.
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.

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.


*Alessandro Castellani*
Lead UX Architect
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20190430/6be7e3b8/attachment.html>

More information about the tb-planning mailing list