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
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.
Analysis
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
Evaluation
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.
Conclusion
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.”
-Josh
UPDATE
This concept has been brought to life. Check out my project Reveal with Conrad Kramer on Cydia today! Watch this video to see how Reveal works.
© 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.
Analysis
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)
Evaluation
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
Conclusion
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.
- Josh
UPDATE
This concept has been brought to life. Check out my project Reveal with Conrad Kramer on Cydia today! Watch this video to see how Reveal works.
© 2012 Joshua Tucker
