E-mail App [Prototype]
I use (and have tried) a lot of email apps (both on iPhone and android), and I never find the right one. I never liked the UI nor the way I interact with them. So I decided to challenge myself and try to design & code* a prototype. The point was not to create a "real app" but to experiment and let my inspirations flow.
You can try it here: https://arnofaure.github.io/a-mail/
Please note, it's a prototype only a few interactions are working and only optimized for Chrome (or any Chromium-based browser: Vivaldi, Brave, Opera,…). You can also use your android phone (might work on iPhone too) but I haven’t tested it.
Tools** used to make this :
- Icons design / and layout research: Affinity Designer + Figma [early stages only: links to board 1 / board 2]
- Text Editor: Atom
- HTML5 / CSS3 / JS
- Gif: Giphy Capture (GIPHY) + Gifgun (AE plug-in)
*I will come back to this at the end of this article
**I am not affiliated to any of the following brands, apps or websites. I don’t profit by mentioning them, they are part of my real workflow and act as daily work tools.
2. UI (User Interface)
When needed, I will note the "what the gesture would be in the real app", but again, as it's only a prototype, I didn't implement them, so I will give you the "prototype equivalent" and you can play with it!
As I wanted to use a font that would be available and consistent throughout all languages, I looked up on the Google Fonts library and chose the Noto Family. If what they say is right:
Google has been developing a font family called Noto, which aims to support all languages with a harmonious look and feel. Noto is Google’s answer to tofu.
So I decided to use only Noto serif and its sister sans serif in the app.
As I said, I never liked the UI for this kind of app. Most of the time they are too busy for me. That’s why I wanted to minimize as much as I could the “text” part of the UI and show only what was needed at the right time. We all live in a world where everyone lives on a smartphone and we are immersed in the world of apps.
Here are all the icons I created for the app. I purposely didn’t put the label on purpose to see if you could guess* what they are. If not… well it means I did a bad job.
* 1 or 2 might be less easy to guess out of the context and I'm sure you will by using the prototype.
Most of the time I think it's (very) difficult to distinguish between the different states of an e-mail, especially between the unread/read email. I don’t get why subtle differences like ‘variation of the colour of the text from black to light grey and/or the bold to regular (font weight)’ is all we get.
This is just not enough for me, and it gets worse as they stack up. Remember Gmail anyone?
So I wanted to really accentuate the different states with a clear and simple colour code:
Also, not a big fan of the lists views…
too many lines…too many lines…too many lines…too many lines…too many lines…too many lines…too many lines…too many lines…too many lines…too many lines…too many lines…too many lines…too many lines…too many lines…hard to focus…too many lines…too many lines…too many lines…too many lines…too many lines…on one email only…too many lines…too many lines…too many lines…too many lines…too many lines…too many lines…
…so I tried something different and used 2 x 3 grid with squarish cells. As I wanted to have big "boxes", I limited the number of emails displayed per page… and the magic number was 3*2 = 6!
In the end, a combination of :
- the square emails
- the colour code
- the emails limitation, 6 per "page"
works better… at least for me
3. UX (User Experience)
I'm not a UX designer per se, and even if there are beautiful UX animations out there, plenty of them are a bit too fancy. Sometimes I'm more fascinated by what the animation looks like (and they were made) than the function they're trying to convey. So it becomes a distraction more than anything else. That's why I'm more into the simple, subtle and straight to the point ones.
If I may — as a video editor for 15+ years- I would compare them to transitions between two shots, nothing is better and more powerful than a simple and well thought cut. Generally, if you need to use something extra (wipe, vfx, etc), it means you're trying to cover it up, not to make the transition works better…ok… that’s a discussion for another time… let’s get back to the subject at hand.
So, to sum up, I think an email app should give priority to quick access, review and help us focus on what matters the most: "Keep your inbox empty!".
So let's start exploring.
- Top Menu (Filter the category/states)
A quick menu to filter your e-mails by category: unread, snooze, read and archive.
Gesture: Swipe Down [prototype: click on the icon]
- Preview Panel
I 'd like to quickly scan my emails, before focussing on them, that's why I came up with this Preview panel, where you can quickly read a few lines and decide what to do with it: Snooze it, Mark it as read, Archive it or Delete it.
Gesture: Single Tap on the action
…and of course you can also read it in full right away with an elegant swipe down.
Gesture: Swipe Down [prototype: click on the top part]
- Read/Reply Panels:
To reply you would have to swipe left, then choose between: Reply, Reply-to-all, Forward.
Gesture: Swipe left + tap on the reply/forward icon [prototype: click on the sender name + click anywhere to close it]
- Search Panel:
A pretty straight forward "search" feature.
Gesture: Swipe right [prototype: click on the 2nd row of e-mail, sender name: "Oliver Painkin"]
- Write Panel:
A very simple and clean panel to write without distraction.
Gesture: Single Tap on the pen icon
- And finally, the *** mode:
You might have wondered what this icon on the bottom-left corner means…
…well, as you may know, we are all addicted to our smartphone and I was thinking that some extra help might be useful if we'd like to disconnect from time to time.
So I think a distraction-free mode that blocks our app for 60 minutes* could be a great thing! And we should not be able to cancel it whatever we do.
*only 20 sec. in the prototype
Gesture: Long Press on the "stop" icon [prototype: single tap/click on the icon]
3. My approach: Design & Code
When I started this experiment I didn't know how I wanted to make it. As I said earlier, I have been a graphic designer and video editor for 15+ years, but as I just started to learn code (html, css, js) a few months ago, I had many possibilities to work with.
I started with my routine: putting directly my ideas on my computer. I started with Figma and switched to Affinity Designer (at that time Figma didn't have the components feature). That was the easy part, then I have to decide which way to go. Because I was not aiming to create a real app, I could :
- Create a motion graphics video with After Effect
- Design all the panels, export them as static png and use a very quick prototype app like Adobe Experience Design CC
- Have the courage to code everything from scratch with html, css and js
I had to weigh the pros and cons and decide where to go.
- PROS: easy to do ; quick.
- CONS: at the end it would be just a video, and I will not learn anything about the process of making a prototype. I could even create some interactions in motion design that could be impossible to reproduce in the "real world".
Quick Prototype (with Experience Design CC):
- PROS: easy ; test quickly the feeling of the interaction.
- CONS: the interactions are too limited to really have the sense of what the "app" could be. And I wanted to try more complex interactions, more than "just" push and fade.
I know that there better prototype tool like Framer, but I didn't want (nor had the time) to learn how to use it before making this prototype.
Code everything from scratch:
- PROS: learn a bit more about coding ; have a better feeling of what the app could be.
- CONS: I didn't know how to do it as my code level was (and still is) very low ; it would take much more longer to make ; am I really ready to do it that way?
And as you could have guessed with the title of this part, I did chose the last one: Code everything from scratch. It was a challenge for me, but I'm glad that I did it. I learned so much more. And regarding my design, I think it has been improved by the code, and it's not the first time I realized that.
Indeed, since I started to learn to code, I am now more aware of what I do and why I do it. It could sound a bit naive, but before writing my
first line of html I had no sense of how an app/software was made. I never wanted to learn how to program, because I didn't see the point and I think it was a mistake.
Nowadays, it's easier than ever to "create" something without any effort or even without knowing how to do it. And I fell into that trap too but I have a good reason — of course we all have! I was fooling myself because I thought I learned enough, because it took me a long time to master the professional graphic design softwares required. Yes you know those powerful softwares that makes your job look extremely complex with an austere UI just to make you feel "pro"fessional. Anyway, I think I should have learned some code basics at the same time I was learning those graphic softwares.
For example, when I was learning video/film editing, I learned the basics first. My teacher forced us to edit on an U-matic VO-9850 editing VTR for hours before allowing us to touch this new non-linear editing software called AVID. What an U-matic VO-9850 is? Well here is her Majesty:
No, I'm not 100 years old — yet, It was in 1999. In short, with her, you could only make cuts (no crossfade, no wipe). You also needed to have an edit plan beforehand, because you couldn’t "move" your shots here and there like you can do today. If you made a mistake, you had to start again from scratch. I'm telling you this because I'm really glad to have been pushed to learn this way. Of course, I was not pleased at that time, I wanted to grab a mouse and play directly with the NEW tool, but I think I would have not been a good editor without understanding the basics of how the shots interconnect together. And I would not have been able to learn it with a non-linear editing software because of its unlimited undo and its flexibility.
Today, I still don't plan to be a programmer/developer but I think knowing what you do helps you to do a better job. Furthermore, designing with code is often much more efficient than using a visual design tool. For example, changing some attributes of multiple elements is faster than with a visual software.
Here is an example where I change the border radius and the background color of 4 different elements with just 2 lines of code (CSS):
Here is the codepen if you want to play with it: http://codepen.io/studionora/pen/rWZMgP
PS: of course components are now on most of the design apps, but as I said earlier, I do believe that knowing how it works makes you a better designer.
I’m still far from being fluent in code but I think I will use this approach of Design & Code in my future experiments and design projects.
And the best part, is that I'm starting to see the code like this geek guys from 1999…
Thanks to my friend Sinj Karan for helping proofread the text.