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.
Here are the fullscreen images for my Actions Widget concept plus an example Calendar view on Dribbble.
Original posts:
Full screen images for the second revision of my Safari for iOS New Tab View concept.
Original post on Dribbble.
Full screen images for my Safari for iOS New Tab View concept. This first part highlights the Top Sites tab. Original post on Dribbble.
Full screen photos for my Do Not Disturb Calendar Integration Concept on Dribbble.
Over the last two years, as I’ve continued to grow and learn more about design, my diligence to truly evaluate the features people have suggested for iOS and my own projects has increased. I often found myself indulging in something based on the “how cool would it be factor” instead of taking the view from the sky and deciding the validity of the idea based on the important fundamentals: security, usability, functionality, etc.
Although I have much to learn and understand, I am confident in writing my point of view on the iOS lock screen and what should and should not be accessible from it. Many times has this topic come up in discussions online and offline, but I have yet to find a solid source that elaborated on the specifics. This is my goal with these “series” of posts. I am breaking up the discussion in bite-size chunks as to not overload people, including myself. I can’t discuss everything on each topic in a post either, so I’ve opened up a way to discuss more dynamically (see Branch).
The main question of this discussion will be:
“What should and should not be accessible from the lock screen and why?”
Part 1 will focus on the issue of security.
Security:
The security of the user and his or her information on device is extremely important. Regardless of whether a passcode is set, what can be viewed or done directly from the lock screen should be an issue of great concern. As a point of critique, I will use a common feature that jailbreaker’s love; quick send.
At the core of lock screen security, I believe it’s extremely vital that a user shouldn’t be able to perform any action that requires or allows someone to search Contacts. This is why quick send from the lock screen is a fundamental security flaw. Someone can start a new message and search through all your contacts, viewing data such as phone number or email address. But one might argue “Siri allows you to call, text, etc. from the lock screen, so quick send is no different.” This is not true, and here’s why. With Siri, you have to be deliberate when you perform any of those actions. Siri awaits a direct input such as “Call X” with X equaling a value which is extremely specific. You can’t search through all your contacts via Siri, whereas with quick send, I can start by typing the letter “a” and go down the alphabet, viewing every contact and their information. That’s a big problem. One might follow up with an argument “What if you prompt the user for a passcode (if set) or require the user to have a passcode on to use this feature?” If this is a question you may have, stay tuned as I will discuss why this wouldn’t work either.
To conclude this section, if any application, tweak, or concept potentially allows a user to search through Contacts, or any data that is considered private, then there’s a fundamental security issue at hand. This is why Apple will never implement a feature such as quick send unless they are able to ensure protection of a user’s private data.
I encourage you to jump in and post your thoughts. Hit up my thread on Branch to get involved.
© 2012 Joshua Tucker
The topic of a “new, revitalized App Switcher” on iOS has resurfaced over the last day as The Verge posted a concept a user did recently on what he feels the iPhone 5 App Switcher should be. After reading and evaluating the concept, I really got to thinking about what I believe in when it comes to a good multitasking design. In other words, what are the make it or break it for a multitasking interface or concept? I have highlighted in the following sections different important factors I feel make or break a multitasking interface or a concept. I will be using The Verge’s concept post as the primary comparison.
Note: I will continue to add more points if time and ideas permit so view this as a “ever-changing, evolving” document.
Three-Way Battle
The proposed Verge mockup for the actual app switching has three basic key components.
1) App preview
2) App icon
3) App name
Out of these three choices, a logical question would be “Which one is the most important?” I would argue that that the application icon is the most crucial part of a multitasking interface. A user, especially on mobile devices, associates applications or certain tasks by its icon, not by the name or action. You can evaluate this on your own by viewing the SpringBoard as an example. What’s larger? The name of the application or its icon?
With this said, I return to the mockup and say that exemplifying the app preview and diminishing the size of the app icon is counter-productive. When I open the App Switcher, the first distinguishing factor is the icon. The icon is the most important part because, all other parts aside, it is the clearest piece of information that tells me the application I can switch to. Period. This concept loses the icons in the preview of the app and increases the time for me to cognitively understand what applications are what.
On top of this, the app previews are so small they essentially waste space and show nothing. Think about certain stock Apple apps have similar base interfaces. Imagine trying to figure them out in such a small view where content within the application is barely visible simply by their app preview? Ouch.
So what is my opinion on what makes this “three-way battle” come out with the right winner? Two things.
1) The icon must be the centerpiece and focal point of app switcher. It needs to be the most important piece
2) If you’re going to use an app preview, find a way to display it so the content is clearly visible and useful. Otherwise scratch it completely
Penthouse or Green Acres?
I use this analogy, because heck, you can’t discount the classic TV show “Green Acres” right? I’m into the classics. But really, I think this comparison fits perfectly with the app switcher interface. The underlying question really is the following:
“Do you want a scenic or compartmentalized view?”
The mockup brings in some new features that would be unique to that view, but I would argue that things are just too jam-packed. The more areas where touch or gestures can be accepted increases the level of error and mistakes. I understand that optimizing the space that is available is important and I’m a huge contender of that, but it must be done in the proper way.
Using the music section of the mockup as an example, the album and music icon are so small that they are barely visible or tappable. For people with big fingers, that could be an issue. Also, in the case of the album art, it’s so small that it’s not particularly relevant to see because you can’t distinguish any parts of the artwork itself.
The most obvious solution would be to split certain parts and put them on another page of the app switcher, but then that increases the number of views to swipe through. So to fix that problem, we have a “big lot next door” we could work on.
So what’s my opinion on this topic?
1) There is effectively 800+ pixels above the switcher that is left untouched. Utilize the surrounding real estate to cut down on things being too close together
2) Bouncing off my first point, if content is barely visible or useful, resize appropriately or cut it.
Law-Abiding Citizen versus Rebel
I will expand on this more when I have time, but if I could describe this section in one brief sentence, it would be the following:
“In the name of keeping our interfaces intuitive with Apple, we must somewhat play by their rules, but that doesn’t mean we have to think in the sandbox of what exists.”
The linen app switcher interface has been a part of iOS since the beginning. I would argue that to include a lot more of the features that people would want in a multitasking interface, that we need to start thinking outside of the linen box. Go beyond what exists and create something that still fits the iOS native profile but utilizes something new and unique.
I’ll be back with more! Stay tuned: feel free to tweet me on Twitter — @joshmtucker.
© 2012 Joshua Tucker
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
