Yesterday, I got in an interesting conversation about Settings toggles. The other person and I both agreed that having the actual on/off switch in the root of Settings was the most traditional way to display it, but we wanted to find a solution to following:
“How can the user toggle certain settings that have the toggle one cell deeper in Settings from the first page?”
The reason why this topic was important is because “in the name of keeping specific settings organized,” it’s better to keep the toggle and its respective settings all together. But on the other hand, it adds one extra step and makes it less convenient to switch certain toggles easily. The release of iOS 6 would make the solution we were seeking much more significant.
To keep all the settings of one specific setting in a unified view and allow the user to easily toggle just the switch from the first page, I formulated the following solution: swipe cell toggling. In the most basic of terms, the user would be able to switch a setting on or off by simple swiping over the first cell in Settings. Naturally, the text would change depending on which one you’re on i.e. “Swipe to enable, Off.” One view deeper in that setting’s panel, the on and off toggle would still be available and would dynamically change via swiping or simply tapping the switch.
——————————————————————————————————————
Here are answers to a few questions that could be posed.
“Why keep the actual on/off switch in the setting’s panel? Isn’t it redundant to have a swipe and an on/off switch?”
It isn’t and here’s why. It’s displacing for someone to have to leave a view in order to toggle something. For example, if I was in the Location Services panel and wanted to turn it off from there, it would just be easier to go to the top and disable it versus having to leave the view to do it. I base my judgement on an example like the volume slider in the App Switcher. The volume buttons perform the same function, but having the slider is an easy alternative and is located right in within grasp of what view you’re in. My implementation of the swipe in conjunction with the on/off switch is on incorporated on the same premise. The swipe is added as a convenience, not a replacement.
“Why do you keep the swipe cells the same size? The cells in Settings > Notifications display a second line of text but are bigger.”
In comparison to the cells for Notifications in Settings > Notifications, the swipe cells are not displaying anything that is potentially significant. With the notification profile cells, the user is looking at it to see whether things like Badges, Banners, or Alerts are enabled. Viewing and knowing what each notification has set is important from that view. But when it comes to swipe cells, the second line is a reminder; a simple guide. It’s not meant to alert you of something that’s set. As the user becomes more familiar with how swipe cells work and where they are used (where info like “On/Off/Connected” is displayed on a cell), then it won’t be necessary to prompt them anymore about how to perform the action.
“Why even notify the user at all with the “Swipe to disable/enable?”
Prompting the user is important if there’s no clear indication of how to handle something. Swipe gestures are difficult because there’s no great way of alerting the user that swiping it will perform something with a symbol. Especially when it comes to de-cluttering the view. And in any situation, the user needs to know exactly what he or she is doing and what will happen when any actions is performed. At this current time, using a text string prompt is the best solution.
“The swipe cell functionality applies to other settings, not just Location Services?”
Absolutely. The implementation of swipe cells would be incorporated in every applicable area. Consistency is important so bringing all scenarios to the same level would be the only way to go. It would work on cells like Wi-Fi (although not shown), Bluetooth, and others that will be available in iOS 6.
“How does this work within the scrollview?”
The swiping is down horizontally and would not conflict with the vertical scroll that’s already native.
——————————————————————————————————————
Note: I always value suggestions, opinions, and even opportunities to engage in a conversation. Discussions are for seeking knowledge and improving upon ideas. Feel free to comment below or contact me on Twitter.
© 2012 Joshua Tucker
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
