AquaMail Forum
English - Android => General Discussion => Topic started by: lpetkov | Mobisystems | Designer on February 28, 2017, 05:06:11 pm
-
Hi guys,
As I said, we'd like to try and keep the community in the loop, and gather (and potentially address) feedback on things even before they are in development. Don't know how often we'll do this, but here we go!
Here's an interactive prototype (https://framer.cloud/raMbP)for a screen that would replace the current Add an account dialog. This isn't something that would immediately affect most of you, but it would be among the first things that new users would see, so we wanted to make it cool and sleek.
The prototype is best viewed on a either a desktop computer with Chrome, Safari or Opera, or on a 1920x1080 phone using the Framer browser app (https://play.google.com/store/apps/details?id=com.framerjs.android&hl=en).
This only demonstrates a single interaction - choosing an account type.
Let me know what you think!
Thanks,
L.
-
Cute.
-
That looks quite nice to me; like the tiles in notifications etc.
One comment though; for users just coming to the app, I'm not sure that the "Stronger security (OAUTH2)" (in the Gmail and Outlook options) is very meaningful if they don't know what the security is stronger than.
HTH
-
Hi, the button called "Internet Mail" sounds strange, even for beginners.
What about "Other" instead?
-
Hi, the button called "Internet Mail" sounds strange, even for beginners.
What about "Other" instead?
I had the same concern. But I am not sure what would be better.
Moreover, I am a bit bothered by the fact that this 4 items are not exactly "parallel" structure.
So, you have two that are specific to providers (both using OAuth2), and then two that are EWS and IMAP/POP.
I get the same uncomfortable impression as when I see at a store several type of salami: "beef salami", "pork salami", "Estonian salami".
I understand that many users have no idea what "IMAP, POP, EWS" mean. But it still irritates my sense of logic.
In the highly-technical world, I'd have it as
Oauth2
GMail
Outlook
Exchange
IMAP and POP.
But I understand, that for many non-technical users this would be confusing.
And I understand that the classification in this case is partially based on the "use cases".
(But only partially, because there are other specific providers are also configured under "Internet Mail".
So, please consider something like this:
Gmail (OAuth2)
Outlook.com (OAuth2)
Exchange Mail (EWS)
Other Mail (IMAP, POP)
That's considering just the visual design.
Now, I'd like to propose a deeper makeover of this screen.
What if someone else, say Verizon-Yahoo, Yandex, ... will come up with a well-implemented and documented OAuth2 implementation. Are you going to keep growing the list of entries on this screen?
To resolve that elegantly, I suggest one of the following to ways:
1.
OAuth2 (GMail, Outlook, something-else)
Exchange Mail (EWS)
Other Mail (IMAP, POP3)
2.
The alternative (totally use-case-based!) would be to list all the preconfigured providers, and then have
"Other", with a fork to Exchange Mail and IMAP/POP. I.e.
Gmail
Outlook.com
Yahoo.com
Yandex.ru
Orange
.....
(long list)
......
Other
Where after choosing "Other", the user gets a choice: "Exchange Mail" or "IMAP/POP".
I think #2 would be ugly (right now all the magic is happening inside), so, I'd vote for #1 of these two.
Actually, with that in mind, I'd even suggest a more radical solution: hide OAuth2 behind one of the categories. Make it totally magical for (most) users.
3.
Top level:
Exchange Mail (EWS)
Internet Mail (IMAP/POP)
If "Internet Mail" is chosen, and the user enters his/her address as @gmail.com or @outlook.com, - provide an option (as a check-mark on the same 1st screen, or as an additional choice screen): OAuth2 or standard IMAP/POP.
I understand that this suggestion is beyond just visual design and includes functional/logical design, - so, it is for consideration of both @Kostya and @lpetkov.
PS. @lpetkov: welcome to the forum, L.! And thank you for listening to Aquamail users.
-
Yeah, we're also having discussions on labeling and the explanatory help texts and how to improve them. Thanks for letting us know what you think!
Glad you guys dig the actual interaction so far!
(Thanks, @StR!)
-
Add an X to easily delete the contents of the bcc.
-
Add an X to easily delete the contents of the bcc.
@someone:
The design team is already aware about the need for a modification of the fields "CC / BCC, Reply-To". Kostya's reply / feedback you will find in one of his recent posts:
https://www.aqua-mail.com/forum/index.php?topic=5408.msg32730#msg32730
-
Actually a bigger concern of mine, for the "really novice users" is that the help text is not visible until the user taps an "account type button" -- which he/she may not know to do until they're "really sure" about what the right choice is.
And if they don't see the help text, they may get to that "really sure".
That the "Next" button is hidden until one particular type is selected - may add to the confusion, because the user may think that just tapping one of those buttons will immediately proceed to "next stage", and what if they make the wrong choice?
To summarize:
- Initial UI: account type buttons, no help text, no "next" button
- The user does not know _yet_ that 1) tapping a button will show help text with more info that would help him/her choose or 2) that it will not immediately proceed to "next stage"
- Impression 1: "which one do I select now, no idea, wish they'd have some explanation or something"
- Impression 2: "and what if I tap the wrong one, it'll just go off and do something bad"
One idea to resolve it would be to *not* hide the "Next" button, but rather make it visible and disabled initially.
This way the user will know that the selection process is two step and won't be afraid to tap one of those buttons. And then when he/she does, there will be help text to help with choosing.
-
I'll prepare another version of the prototype without the auto-hiding button
Sent from my Nexus 5X using Tapatalk
-
Hi all,
I rewrote and updated the prototype:https://framer.cloud/Utemm
Much smoother animations + a button that's always there, but switches active/inactive states.
We're still discussing the labels and the help texts, so that hasn't been addressed yet in this iteration.
Thanks,
L
-
Just a quick observation:
You have lots of empty space at the bottom of the "help" text for all 4 items.
It looks strange: asymmetric (top vs. bottom text margins for that text box), and just large without any apparent need (especially when you have only 2 or 3 lines of text as in # 1,2,4).
Is it to accommodate the "largest" (+2) font being used in the app?
If yes, - that's great that you've thought about and tested (?) for that.
But even with that, since the standard system libraries will most likely be used for this implementation, I hope there is a technically elegant way to accommodate different font sizes without unnecessarily buffing up the margin.
HTH.
-
I believe these text strings will only use a single font size.
What I'm taking into consideration here is that we'll be translating the strings into a few languages, which means that the number of characters is a variable.
When we test this layout in development, we'll adjust the height of the cards accordingly :-)
-
Aah... That's wise!
Please, excuse my question/comment, as I've never worked with any Android libraries:
Maybe naively, I'd expect that in 2010-s, Android libraries should allow "dynamically-sized" text boxes ("cards"?) that accommodate the text provided, -- to avoid hard-coding the size of them. In that case, only the margins around the text need to be specified, not the size of the box.
This is typically done in good HTML design and in presentation/publication design tools (PowerPoint, InDesign, ...), so, I'd be surprised it is not available in Android. (But my intuition and logic have been proven wrong in Android a few times.)
-
In general, I like the new suggested design. Two questions come to my mind:
1. Order
I would recommend keeping the order as it was, i.e. with Internet Mail before Mail exchange.
2. Explanations
The current, less nice, setup has a description under each button. The description lists what fits into each category, so that if a user knows that their ISP has POP or IMAP' they know they need to click on "Internet Mail". Likewise, if they know their corporate email uses Kerio rather than Microsoft Exchange, they know they need to click on "Internet Mail" (whereas the Gmail application on a Nexus phone required connection via the Exchange protocol).
Where will be those explanations?
If they are at the top of each page (ex.: once a user clicks on "Internet Mail", he or she sees the description), then it's not too bad, even though it still means the user might make a wrong selection and have to go back, try a second selection, etc.
If there are no explanation, then users will try their luck with one of the option and will have to try a few options before knowing which one works. They will either complain and look for support on the forum, or complain elsewhere and walk with their feet. If that's the first account they try on the free version, they are likely to uninstall ASAP. If that's their 2nd, 3rd... account they install after switching to the Pro version, then you'll see the negative publicity on Google Play.
-
@mgagnonlv:
It might not be obvious (it was not obvious at first to me), - but on that mock-up, you can click on the menu elements (at least in a desktop browser [I tested on Windows]). I am not sure how it works with a mobile device browser... (There is an app for mobile devices for that.)
That will present the "help" cards.
-
I agree that "Other" label is better and a line of explanation in each box would be good for first sight.
-
Re: "Kerio is not supported" seems confusing to me and probably to more than 80% of users
Maybe, but there are some people trying to connect Kerio as an Exchange account and it fails.
I'm not married to this part of the text though, and there is information about Kerio in the FAQ anyway.
-
A "mooving frame" where blocks move to let help text appear, then stay larger than other blocks with the text until the user touches another "choice" seems rather complex. Large button "next" is too large and does not help in making the process self explanatory.
The current flow is simpler: the user sees everything in a static menu, and presses "OK" to go to next step. Isn't possible to just redraw the current screen, without changing the selection behavior? As an improvement, I would recommend to use less text ("Kerio is not supported" seems confusing to me and probably to more than 80% of users)
Please take a look at other email apps accout creation process (I suggest TypeApp): I have just checked it and it is simpler and clearer IMO.
Technically the selection behavior is the same - its just that you don't tap on a radio button, but on a material card. You still make a selection and press a confirmation button, same amount of steps.
The benefits I see are cleaner UI with larger text + large icons, no radio buttons. No 'wall of text' effect as we show the help text bits only where you tap (generally, users hate reading (https://www.nngroup.com/articles/how-little-do-users-read/)). Please keep in mind that the expected behavior for most people is to just tap on one of the options and then tap Next.
(my assumption is that most people who know about email clients also would kind-of know they have a Gmail account or an Outlook account, etc).
Thanks for your feedback.
-
I also believe that Internet Mail might be confusing and that Other might be better.
To address kostya concern I would start with a selected account, then the user will understand that selecting another will open an explanation or will realise after a couple of clicks.
-
Maybe naively, I'd expect that in 2010-s, Android libraries should allow "dynamically-sized" text boxes ("cards"?) that accommodate the text provided, -- to avoid hard-coding the size of them. In that case, only the margins around the text need to be specified, not the size of the box.
Yes, certainly.
-
Thank you for confirming my guess, Kostya!
That possibility makes it unnecessary to pad the text with any empty lines (inside the text boxes/cards) -- to allow the text in other languages to fit as well.
-
That possibility makes it unnecessary to pad the text with any empty lines (inside the text boxes/cards) -- to allow the text in other languages to fit as well.
Might have been a limitation of the prototyping tool.