Based on the pictures above, I have proposed the following:
The main page of the Mail interface should be arranged in a hierarchal fashion. Inboxes can collapse and reveal folders within them, thus removing the need for an “Accounts” section. The space left empty due to the unification could be allocated for something such as an RSS inbox.
Note: I do not claim to be an expert or master on this subject. I’m still learning and eager for feedback. What has been written is based on my own personal analysis which includes my experience in this field.
I rest my concept on principle number nine from the book 100 Things Every Designer Needs to Know About People by Susan Weinschenk
People believe that things that are close together belong together
As such, if the user feels that a component is connected to the main branch, they will understand its purpose in the interface scheme. This establishes familiar gestures, methods, or other types of user-initiated actions for more then just one part of a page.
One argument, that I would suggest to you, is that Apple’s aim is to unify iOS and OS X to make one single OS for the betterment of all devices. Although there may be no disagreement, this plays a significant role in how to move forward in both systems.
For a moment, let’s briefly evaluate how the Mac handles mail in the way I’ve proposed it for iOS.
- Inboxes are ordered in a hierarchal fashion
- These inboxes can reveal and hide folders based on clicking
- Whether hidden or in view, there’s a connection between what folders are with which respective inbox or folder (depending on how deep folders go)
In the name of unity, I would propose that this functionality could be beneficial in iOS. Tapping the inbox icons would reveal or hide certain sections, as distinguished by an arrow to alert you to whether it’s open or closed. Because each section would fall under its associated folder or inbox, the user would understand its connection and could more easily navigate through the various folders; a supporting factor to Weinschenk’s ninth principle.
This would relieve the “Accounts” section giving space for something else. Whatever that may be, in this case an RSS inbox. To prop up my thinking on this matter, I once again direct you to OS X to see what it holds.
Jumping to Mail once again, let’s head to Preferences. In this pane in regards to Accounts, we find the following.
- The Accounts section lists accounts that are added and are in the Mail application
- In this section, the settings of the accounts or inboxes can be changed and (or) updated
- There is no connection to actual folders or organization of them in any way
How does this play out in iOS? I would suggest that this mindset might throw off the user when using Mail. A new user could be confused by the notion of an “Account” section, where in the OS X example, only deals with settings and configurations.
When it comes to existing users, I feel that compartmentalizing sections and unifying components not only allows for better organization and gains space, but it moves parts forward to bring a unique but similar experience between all devices.
As for RSS, I chose this feature for the following reasons:
- It promotes unification with OS X and its functionalities
- Coming into one collaborate area is better for reading and dealing with notifications
One might argue that RSS should go into a separate application or in the Newsstand. I don’t disagree with having a different application, although for simple and easy RSS reading and managing, I don’t feel there’s a need.
Newsstand on the other hand, I don’t feel is the right place. The reason for this is because RSS is not just news. On that simple basis, it doesn’t fit. Also, RSS is generally just text and comes in as such. Because Mail doesn’t preview images and only shows them as attachments, keeping the feeds that work and perform similarly gives this sense of belonging or a reason to why it should be there versus another place.
Note: Adding favicon support is possible, however the icons would have to be sized correctly to fit the specifications (most favicons would be too small and would look distorted if stretched to size).
Also, RSS is not necessarily an end-game feature. This is an example of a possible addition.
Here’s a list of functionalities this incorporation could or would have.
- Unified inboxes and folders
- Collapsable sections - tapping the arrowed inboxes or folders reveal or hide them
- An RSS inbox
All iOS devices would support this feature.
“There is nothing wrong with change, if it is in the right direction.” - Winston Churchill
© 2012 Joshua Tucker
Earlier this morning, I posted an idea for scrolling text on iOS notification banners. I made note of the fact that the lock screen is a viable place for this implementation as well. However, there are two significant differences between lock screen notifications and the banners.
- Notifications on the lock screen do not clear until the device is unlocked
- Lock screen alerts show more than one line of text.
With this in mind, I feel the best way to go about scrolling in this view is to do it like native iOS - vertically.
In this post, I will be discussing my thoughts on how to go about this when in the bubble view.
Note: All measurements are rounded to the nearest whole pixel.
Here are some important figures to note:
Number of Characters Visible (Unexpanded) = 130 (including whitespace)
Full Size Bubble Dimensions (Unexpanded - Max Characters) = 262 pixels by 592 pixels
I find that the best way to alert the user that the bubble is selected for scrolling is by expanding it. This can be done by simply tapping it. Upon tapping it once, it will expand and show more text (three new lines). However, if you scroll your finger through the bubble, you can move up and down through the message. To exit the selected bubble view, tap it again and it will resize.
Note: The scrolling bar on the side of the bubble in the picture is only viewable when you scroll (just like native iOS).
Here are some more important figures to note:
Number of Characters Visible (Expanded) = 225 (includes white space - scrolling allows the user to view the entire message thus making it an infinite amount of characters that can be viewed)
Full Size Bubble Dimensions (Expanded - Max Characters) = 297 pixels by 592 pixels.
The reason why I chose it to be these dimensions and allow three new lines is because, if resized evenly, it expands just a tiny bit but allows three more lines of text. It will look clean and still won’t completely cover the screen. Plus, the importance of the expansion is to alert the user that they can scroll in this view. Making it any larger would surely make the bubble obtrusive in my opinion.
As all the core information is above, here’s the full message I sent myself.
“Tap to select the bubble. It will expand at that point and will allow you to scroll through the message from top to bottom and back again. Tap the bubble again to bring it back to normal. This will still allow full compatibility with Abstergo.”
© 2012 Joshua Tucker
Due to the fact that the banner can only stretch as far as the length of the iOS device’s screen, many times characters and words are truncated in order to fit. A way to alleviate this issue would be to implement a scrolling ability through the text like in the Music application when the name of the song or artist is longer than what is viewable.
Note: Although this is oriented towards banners from the SpringBoard (while using the device), this could apply to notifications that appear on the lock screen as well.
After timing and toying around with the implementation of this feature in the Music application, I came up with some figures alongside facts on the banners themselves that would make this addition viable and user friendly.
Note: All figures are rounded to the nearest second.
View Time of Notification Banner = Seven seconds (approximate - based on three counting tests)
Number of Characters Viewable on Banner = Fifty-four characters (includes whitespace)
I preceded to Music to do some timing tests on how fast the scrolling was when playing a song. My tests were undertaken as follows:
The text (in this case the artist) disappears from view as it passes under edge of the bar. As soon as it started moving again, I counted to one second and benchmarked in my mind where the text was at the time when I went to two. I then counted the number of characters that were already hidden before I moved on to two. I did this three times to ensure better reliability in timing.
Number of Characters Scrolled Per Second = Nine characters (approximate - includes whitespace and based upon three measurements)
Now, with these numbers, let’s see what happens. For the best user experience, the banner needs to stay on screen without motion for a least one second. This will allow the user time to focus on the banner itself and what text is on there.
9 x 6 = 54 characters in six seconds
54 (what’s already visible) + 54 = 108 characters
With this said, you could read most likely read an entire text message and almost an entire tweet (maxed out at 144 characters) by the time the banner disappears from view. And this would all be done at a pace that is easy on the eyes and user intuitive.
As an example, if this had been implemented, you would have seen the entire message I sent myself in approximately three and a half seconds:
“Imagine if this scrolled like a stock ticker. The banner stays for about seven seconds.”
Similar to how the Music application handles this, the text would disappears as it hits the edge of the character cell (the divider before the icon on the far left). If the text is too long for the screen but not much, it will scroll again through the message if time allows. However, it will always wait one second after returning before scrolling again.
© 2012 Joshua Tucker