Full screen images for my third revision of Lock Screen Actions.
© 2013 Joshua Tucker
Many people have addressed Do Not Disturb and questioned why there isn’t a toggle for it in the iOS Notification Center. Often, the justification is that OS X has a Show Banners and Alerts feature in its Notification Center therefore it could be a viable to add Do Not Disturb in a similar fashion. The conversation arose again a few days ago, so I decided to sit down and think about my own personal thoughts on the matter.
What is written below, along with the images submitted, is a collection of my analysis on Do Not Disturb as well as my solutions to the inquiring minds. They are strictly my opinion based on my own personal experience, but I hope to shed some light on a topic I feel hasn’t been focused on as in-depth as I attend to with this post.
Do Not Disturb vs. Show Banners and Alerts
First, I will begin by explaining the difference between these two. Sometimes their differences can be overlooked and I want to put their “definitions” on the table so to speak so I can move forward with a solid foundation.
Do Not Disturb - A feature on iOS which allows the user to silence any calls and alerts from the lock screen when enabled.
Show Banners and Alerts - A feature on OS X which allows the user to show or hide banners and alerts from the desktop when enabled.
From the core, these two features are starkly different – Do Not Disturb functions only when the device is locked and Show Banners and Alerts only works when computer is in use (by nature of the OS). With that said, the implication of these features is the following:
Do Not Disturb is designed to keep you uninterrupted when you’re not using your device while Show Banners and Alerts keeps you uninterrupted when you’re using your computer.
In simple terms, one serves for when a device is not in use while the other serves while it is in use. That’s a significant difference. When Do Not Disturb is enabled and you’re using your device, it is not in effect. You still receive notifications (banners and alerts) without interruption. Therefore, placing a switch for Do Not Disturb in the Notification Center doesn’t make sense.
Do Not Disturb doesn’t mandate SpringBoard notifications (banners and alerts). Even with it enabled, the device still shows banners and alerts like normal. By placing a toggle in the Notification Center, it makes a false impression on the nature of Do Not Disturb and just adds clutter – it doesn’t make sense.
A logical response to this could be:
“Then why not make Do Not Disturb hide banners and alerts too which would make this feature work in the Notification Center?”
There are many issues with why that wouldn’t be a good solution, especially for users who have it scheduled. Another tack-on suggestion could be:
“Add a Show Banners and Alerts option within Do Not Disturb.”
Although it is an option, it adds more complexity than the user needs to handle. If the user has to think whether that option is enabled before enabling Do Not Disturb then it removes the ease of knowing exactly what you’re doing when you toggle the switch.
Hopefully, you see why I feel that a feature like Do Not Disturb and Show Banners and Alerts are two separate entities and would wreak havoc if placed together.
So, what if I want best of both worlds?
Like the title says, what if you want both features? A way to keep you uninterrupted when you’re not using your device as well as when you are? My concept photos show what I feel could be a good way to integrate them both.
In the images I submitted, you’ll notice that it has the following disclaimer:
“Do Not Disturb is enabled. Calls and alerts that arrive while locked will be silenced.”
This only shows when Do Not Disturb is enabled. Why did I add this after digressing into why Do Not Disturb doesn’t belong in the Notification Center? Because it is applicable to let the user know of its current state. Although Do Not Disturb doesn’t mandate banners and alerts on the SpringBoard, iOS still stores all the notifications you receive even with it enabled. And despite being an “advanced user” so to speak, and having a status bar icon, I forget it’s left on sometimes.
This isn’t a problem I face alone. I have had three friends in the last two months make a comment that they couldn’t figure out why their device wouldn’t buzz or ring. They mentioned they finally discovered that it was this feature called “Do Not Disturb” that was on. Two of them said it took them over a week to figure it out (the last said over a month). The prompt in the Notification Center, I feel, should help in reminding even the most “advanced” of us that Do Not Disturb is actively running. In my mind, this would always be in view in the Notification Center until it’s turned off. On top of this, having some type of alert after a significant amount of time that Do Not Disturb is turned on would be great integration as well.
But this message won’t be displayed in full view all the time. Pulling down the shade will reveal a Show Banners and Alerts toggle along with the text. Toggling it, similar to OS X, will turn off all banners and alerts from showing on the SpringBoard. When turned off, a status bar icon will show to notify the user of its state (next to the battery percentage). Since the scrollview in the Notification Center is very fluid, it won’t be hard for the user to discover the Show Banners and Alerts toggle as well as check its state in the even they forget (or don’t look at the status bar icon). You can hide the toggle and the text by pushing the view back up again.
As mentioned in the field, it will toggle itself back on again tomorrow. One might ask “Why not have a similar un-toggle feature for Do Not Disturb?” It would conflict with Schedule and wouldn’t help in users figuring out how to use all of its features.
I would love to hear your thoughts, concerns, and insight on this topic. Feel free to comment below or hit me up on Twitter.
UPDATE: I have started a project with a developer to bring this to life. Coming to Cydia in the near future.
UPDATE 2: It just dawned on me. Think about Power Nap as being the OS X equivalent to Do Not Disturb. The implication is that your device is not in use and doesn’t interrupt you (you don’t have to leave the lid open or disable your computer from sleeping).
© 2013 Joshua Tucker
As promised, here are fullscreen shots of my Reminders for Messages on iOS concept. Check out the original Dribbble post for full details.
For all my Twitter followers who replied or saw my post, I polled all you guys on the following question:
#Poll How do you most often end a phone call?
A) Use the “End button”
B) Use the Power button
The reason why I asked this is because I wanted to point out an interesting inconsistency with the Power button while in a phone call and discuss my solution for this issue. You can test this out for yourself and see exactly what I’m about to tell you.
If you’re in the Phone application and currently in a call, there are two ways to end a phone: using the “End” button or pressing the Power button. However, if you exit the Phone.app and come back, the Power button locks the screen instead of ending the call.
I’m someone who accidentally hangs up a call by putting my phone to my face and it hitting the “End” button (I’m sure many of you have experienced the same thing). The way that I keep myself from doing that is to lock the screen. But, it’s not an action that can easily be done. I have to multitask and do something else in order for the Power button to “switch” over to locking the screen instead of ending a call. The inconsistency of the Power button makes it difficult to remember what action will be done.
Since the Power button’s main use is for locking the screen, no matter where you are or what you’re doing, I think that it should be reserved for locking the screen only and not ending the call. For those users who use their Power button to end a call, I would say that there could be a short hold in order to end a call with the button so it’s not confused with simply locking the screen.
© 2012 Joshua Tucker
Now that iOS 6 has pull to refresh in Mail, the refresh button has been removed from the bottom bar. Being someone who always tries to find ways to utilize “dead space,” I thought about something that I would like to have easier access to from that view.
One area that’s difficult to get to in Mail is the folder hierarchy for each account. In other words, you can’t easily navigate to another folder within your account (inbox) very easily. The process to do that now is to go to the main page of Mail and go into one of the Accounts at the bottom of the list. That’s displacing if you’re already in the inbox view.
To make the process easier, I brought a folder button to replace the refresh button inside the inbox view. If you tap that folder icon, it will bring up the hierarchy view and allow you to switch to another folder right from the inbox view. If you have more than one inbox and are in the “All Inboxes” view, all the folders for all accounts will show. But if you’re just in an individual inbox, it will only show folders from that inbox.
You can always quit out of the view and return to the inbox you’re in. Easy peasy.
P.S. If you want an invite to Branch, click this link and “Ask to join.” Come discuss this concept with me there!
© 2012 Joshua Tucker
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
With cell providers continuing to cut back on data and increasing the prices of the plans, it’s crucial to be aware of how to limit your data usage. Push for Mail is a core component of iOS and is extremely useful, except when it eats into your data. You want the capability to have push, but many of us have to disable it due to our data usage habits. However, many of us are in areas where Wi-Fi is available often therefore we aren’t concerned. But at this point push for mail is either an on or off option. And when it comes to Fetch, same deal - possibility of increased data usage.
I propose that an easy solution for this issue would be to allow the user to specify whether push or fetch uses cellular network. In the first picture, note that a new toggle would be added allowing you to decide whether push (if enabled) and fetch uses cellular data. The next following pictures show the options you would have if you go into the Advanced section and select a specific account. If you select either Push or Fetch, it will offer you the option use cellular data for that specific account only.
Hit me up on Twitter with any questions or comments. Or feel free to post below.
© 2012 Joshua Tucker