UI mock-up - Account Setup Rev.2

Matt Harris unicorn.consulting at gmail.com
Thu May 2 08:39:03 UTC 2019



Welcome to Thunderbird
Set up an account.


In this context (the first two images) I think  something like 
"configure your copy of Thunderbird or set up your copy would be more 
appropriate as we have options that do not entail setting up an email 
account which is where most of the flow is going.  I really do like the 
idea of a central "account creation point" instead of selecting from a menu


I would like to see a More information link on the protocol.  IMAP and 
POP are still arcane to most users and the wrong choice is very common.  
The IMAP option also needs work.  We store by default all IMAP mail on 
the local machine., hence users consternation when it disappears when 
they clear everything from the server. (that mail backup/archive thing 
again.)  See https://support.mozilla.org/en-US/kb/imap-synchronization 
and 
https://support.mozilla.org/en-US/kb/glossary-terms-including-types-accounts#w_accounts

There should also soon be a new article on 
https://support.mozilla.org/en-US/kb/difference-between-imap-and-pop3 
discussing the pros and cons

Matt



On 02-May-19 4:10 PM, alex wrote:
>
> Hello folks,
>
> Here's an updated version of the account setup workflow.
>
> https://presentator.ura.design/en/XP9IsbuQ?v=0&s=1&m=preview
>
> *First Screen*
>
> 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.
>
> 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. This might seems like a bit of a stretch, but I'd 
> like to pursue the idea of having a unified "Account Creation Dialog", 
> no matter if the user needs to create an email, add a calendar, an RSS 
> feed, etc. The location and experience should be consistent to prevent 
> unnecessary learning curves or visual inconsistencies between sections.
>
> This section will be pretty modular, so there's no need right now to 
> list which service/feature should or should not be there, since we can 
> change them pretty easily and we will discuss those in a dedicated 
> bugzilla tickets.
>
> *Error messages*
>
> 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.
>
> 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.
>
> *Manual Configuration*
>
> This is tricky since there are many fields and it's really easy to 
> overwhelm the user.
>
> 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.
> 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.
>
> 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.
>
> Cheers,
>
> -- 
> Alessandro Castellani
> Lead UX Architect
>
> _______________________________________________
> tb-planning mailing list
> tb-planning at mozilla.org
> https://mail.mozilla.org/listinfo/tb-planning


-- 
“Against stupidity the gods themselves contend in vain.” /― Friedrich 
von Schiller, Die Jungfrau von Orleans /
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20190502/bd9f0acd/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4008 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20190502/bd9f0acd/attachment.p7s>


More information about the tb-planning mailing list