This concept showcases an enhancement to folders on the SpringBoard to allow the user to switch folders without having to leave the folder at all. To move to the next folder (left or right), simply drag over and the content in the next folder over will come in; similar to how you switch pages on the SpringBoard. The user can move as many folders as he or she wishes by continuing to drag after the folder ahead of it in the queue is fully loaded (again, like how SpringBoard manages paging).
I broke down the fullscreen image into six sections to document how the implementation works.
1) The folder you’re switching from and its label
As you switch to the next folder, the following things happen. The folder itself with its respective icons begin to fade out to match the opacity of the rest of the icons on the SpringBoard. Since the label for the folder that is being switched from is gone when in the folder is open, that label begins to fade in to the level that the rest of the labels are. In this case, the folder “Misc” is fading down while its label is fading in.
2) The folder you’re switching to and its label
This works in the exact opposite of the above. The folder you’re switching to fades into to full view while the label fades out until it is hidden. In this case, the folder “Apple” is fading in while its label is fading out.
3) The dialog arrow on the folder
The arrow plays a key role animation-wise to distinguish that you’re switching folders. As you begin to move one direction, the arrow follows along along the horizontal axis attached with the top of the folder. As soon as it reaches the next folder, it stops. Like the SpringBoard, if you don’t page far enough and let go, it will go back to its original position. If you scroll far enough and let go, it will continue on its own until it hits the next folder.
4) Folder label of the folder that’s coming in and the previous folder’s label
When switching folders to the right (as depicted), the folder you’re leaving starts heading off to the left. The icons head out and the label follows them as well. In the case of this example, the label is already gone because it is on the far left side when displayed normally. If you switch the opposite direction (not depicted), then the label stays shown as you move into the next folder until the new folder takes view. As soon as the other folder is loaded, the previous label is already off screen and out of view.
The incoming folder works the same way. The label follows the icons in and how the label is viewed depends on the number of icons in the incoming folder and which direction you’re coming from.
5) Incoming folder icons
Briefly mentioned above, the icons come in from whichever direction you’re switching. The incoming icons push the previous icons out and don’t fade or perform any animation. Think SpringBoard paging.
6) The folder canvas and other SpringBoard icons
Because the folder canvas changes size based on the number of icons in the folder, the canvas will change size dynamically as you move into the next folder if applicable. That means it will grow larger or shrink smaller as you move into the next folder.
Since the SpringBoard icons (the low opacity icons) change layout based on the size of the canvas, they will move down or up depending on whether the canvas is getting smaller or larger. It will follow in suit to whatever the canvas does. In this case, you can barely see a row of icons poking off the bottom of the screen. When this animation finished, that third row of icons will be visible with the folder “Apple” displayed.
Here are some answers to a few possible questions that you guys might have.
Does this functionality conflict with the native folder handling?
No it doesn’t not. It’s an enhancement. You can still leave folders and go to the SpringBoard or another folder if you wish to that way.
How does this implementation handle switching when the next folder is on another page?
If you switch to to another page, it will simply jump to the next folder and keep the same animation style (which includes the dialog arrow moving into position if applicable)
Will this implementation work on all iOS devices?
Yes it will. Although depicted on the iPhone, the folder-switching capability will be usable on the iPad and iPod touch.
Any further questions can be posed to me on Twitter or in the comments below.
© 2012 Joshua Tucker
Introduction
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.
Analysis
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.
Evaluation
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.
Conclusion
“There is nothing wrong with change, if it is in the right direction.” - Winston Churchill
-Josh
© 2012 Joshua Tucker
