My real name

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

Original Dribbble Post

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

Since the first iOS 5 beta release, developers across the jailbreak community have rushed to create their own widgets on top of Apple’s existing options. The challenge from that point onward has been to build widgets that fit iOS’ existing frameworks; in other words, the goal is to integrate widgets natively into the operating system. The widget “playing field” recently expanded when Dashboard X was released, which allows users to place their widgets directly onto their SpringBoard. As a result, an entire dimension of widget real estate was added for the users to tinker with. 

For those who know me well, I have professed on many occasions that widgets and my philosophy on the purpose of the Notification Center / SpringBoard don’t mesh well. I’m not completely closed to the idea, however I’m writing this post as a way to encourage developers out there to take the three factors below into consideration. I speak only for myself however my hope is that my suggestions are shared by others and that change for the better will occur as a result.

WWAD? - What Would Apple Do?

This is a huge concern of mine. When I look at any widget, my first question is, “Would Apple do it this way, in the event that they did?” Initially, think of it as a “What if” question. The reason why I chose iOS is because of its elegance, simplicity, and the overall experience it promotes. I can say with full confidence that many people share my view. With that said, when you’re creating a widget, be mindful that iOS users want to enhance their experience if it compliments the system they already love, not degrade it.

Take extra time to do “on-device research” to note certain design characteristics and paradigms that will help you build a widget that best integrates with iOS. I guarantee you that your success in development will fair much better if you go the extra mile and strive to promote iOS’ core strongpoints with your widget, versus simply “pasting” your project into the environment just because it adds a function. Great functionality is only appealing when it has great design; it’s a fact. 

Widgets can be used in two different environments

As noted above, the Notification Center from day one has always been the main location for widgets. However, now that Dashboard X is out in the wild, the sandbox dramatically grew in size. With this in mind, you have to remember that your widgets can be used in more then one place. Unless you’re specifically designing your widget for one or the other (which I’m strongly against), take the time to design your project to fit all case scenarios. 

Take this situation as an example: I am a user myself, just like anyone else. I don’t own or use Dashboard X. Let’s say that a really cool widget came out that I wanted but it was only optimized (in look and in its inner workings) for Dashboard X. That instantly raises my red flag. Why would I want this widget if it only works or looks good in one environment? Plus, I don’t even own or want to purchase Dashboard X. 

My thinking is not exclusive to my stance on widgets. There are many people, naturally, who share this view. From the standpoint of downloads and (or) sales, you automatically cut out a huge section of your market when you don’t develop your project for all cases. You’re only targeting a relatively small piece of the iOS user base. Why would you want to do this? It’s a hinderance. 

Everyone wants to be successful - it’s human nature. Success comes through demonstrating quality and excellence in whatever you do. If you have the opportunity to be successful to the fullest extent, wouldn’t you take up that without hesitation? You can do this with widget development. Take the environment into consideration and build a widget that works in each and every situation. You’ll see that people will be more inclined to take a risk and download or buy your widget. A first impression is huge, and you have the means to go off on the right foot from step one. This principle ties back with what Apple would do. They are targeting the entire mobile user base. If there are any components that don’t fit all case scenarios, they’ve instantly alienated a large group of people. I would say however that Apple has done an exceptional job of not going down this path.       

You’re Not The Only “Big App On Campus”

I’ll keep this section short and sweet as it coincides with the above. Remember, there are many more applications and tweaks out there that are popular. You’ve got giants such as LockInfo and IntelliScreenX that dominate their area and their are, of course, other extremely well-favored applications that are the “numero unos” in their own domain. If you want to be just as successful, you must make sure to take other popular applications and tweaks into consideration and design your widgets to work well with all of them. Echoing from above, if you don’t, you cut your audience significantly when you don’t account for the other packages. Compatibility is key - make it a priority. 

These thoughts are not meant to directly slander certain developers and their widgets. My hope from this is to encourage others to strive for excellence and quality in all that they build, create, or design when it comes to widgets. Apple gave us such an amazing system to play with. Let’s compliment the hard work they put into it by in turn firing back with the best we’ve got.

Promote excellence, not mediocrity. 

Photos courtesy of iDownloadBlog and 9to5Mac.

As John continues to code Abstergo to how we both want it, I have expanded into other ideas to tackle after our project is done. The beauty of teamwork is continuous innovation. When one of us is at a standstill waiting for the other, opportunities to test and play around with new things gives a sense of direction after we’re done with our current focus.

Although no name has been chosen, here’s a small sliver of our next project; a SpringBoard manager. This manager is a vast and encompassing project and isn’t fully developed yet. Small parts have been brought from my mind to paper so as sections come together, I will showcase them to you. 

This portion of the project highlights dealing with deleting applications and placing them into folders. It will include my multi-icon mover concept as well as new and unique functionalities. 

Note: My idea for moving multiple icons has changed slightly from the concept above. Information on how I want it to work will be revealed as time goes on. 

I won’t let out too much information, but I will let you know about a couple of things pertaining to this part.

• - You will be able to multi-select applications
• - With multi-select, you will be able to folder them instantly as well as delete them with ease (individual and multiple)
• - The drawer as shown in the pictures will be available to you only in Wiggle Mode and can be revealed by pulling down in the SpringBoard
• - There will be a lot of animations (just enough to be appealing to the user of course)

And to top it off, there’s much more than meets the eye. Feel free to ask questions and I will do my best to answer them accordingly. 

The Question Mark: I spaced on what I originally wanted in that box and I’m searching for the lost recollection of my idea. If you have any ideas, feel free to shoot me them. Hopefully I figure out what I wanted there!

———————————————————————————————————

I leave you with a quote from a man who we’ve all come to cherish and love. For his inspiration and impact on the world. His definition of innovation is what absolutely defines my experience; it’s powerful.

“But innovation comes from people meeting up in the hallways or calling each other at 10:30 at night with a new idea, or because they realized something that shoots holes in how we’ve been thinking about a problem.” - Steve Jobs

Until next time.

-Josh

Twitter: Joshua Tucker, John Heaton

WARNING: Anything and everything is subject to change.

© 2012 Joshua Tucker

Here’s Part Three of my multitasking interface. Recap below to get yourself back up to speed if need be:

SpringBoard Launchpad - Multitasking

SpringBoard Launchpad - Music 

Let’s break it down:

Settings:

If you launch the multitasking/Launchpad interface and select the Settings tab, this will display. As you can see from the images, the settings that are displayed are the ones that I believe to be the most important and “essential” for users to have direct access to. It is scrollable and will allow more settings to be accessed. Three that are not shown include:

• Rotation Lock
• Vibrate
• Data / 3G

Enabling/Disabling:

To enable or disable the different toggles, simply swipe the row area of your choice and it will change from on to off (or vice versa). The text “On / Off” will change respectively and the color of the button will change from green to red (whichever). Once again, it doesn’t matter how you swipe in that area, it will make that change. However, it does have to be a vertical swipe. 

The Brightness and iTunes Wi-Fi Sync areas work differently so they are explained below:

Brightness:

Since there’s no on/off switch, it works differently. When you start swiping in that area, it switches to the slider so that you can change it and what not. The brightness icon on the far right changes shape based on how bright it is. As soon as you change the slider area, it changes. It is important to note that the direction of your swipe is key - swipe and hold right to increase brightness, and swipe and hold left to decrease.

iTunes Wi-Fi Sync:

If you swipe in this area, it will start WiFi Sync (if applicable). It will change to the “Syncing” word and the icon. Obviously, it will also show the native icon on the Status Bar. 

Now to go back and touch up things — stay tuned!

© 2011 Joshua Tucker

The multitasking interface on iOS has been an area that I’ve had a lot of passion for. I’ve run into many ideas and have hit a lot of walls. Here is some of my earlier work:

Multitasking

Multitasking — Revised Version

I decided to go a different route and try to bring in the good characteristics of other Apple products and interfaces and merge them together.

Here’s my idea of bringing the Mac OS X Launchpad concept to iOS and merging the following into one interface:

• Launchpad
• Multitasking
• Music Controls
• Brightness / Volume Slider
• Basically all the multitasking utilities available to you now in native iOS

Initially, this would be a replacement of the entire multitasking interface all together.

Note: This interface can be launched from the SpringBoard and inside applications (not from the lock screen). 

Also: This interface is more oriented towards the iPhone and iPod touch. I have another idea in mind for the iPad. After I’m pretty solid with this, I’ll move onto that. 

Let’s break this down into sections so I can best explain this:

Activation:

This would be done natively (double pressing the Home Button) or by a gesture of some sort. 

Shade:

When you activate this interface, the background as displayed in the photos will pop up. The shade is a mixture of the Notification Center shade (toned down a bit) and a blurred view of the background. The goal behind this view is to keep the experience all together — the focus should be on what is on the shade but it keeps a small sliver of what else is going on to promote a unified experience. 

Applications:

On the shade, applications are lined up for easy access. They are arranged from bottom to top and by last used. That means that the applications that are running are down at the bottom closest to your fingers. The blue indicator under the applications lets you know that the application is running. Just like the native multitasking interface, holding down on the icons will allow you to get to wiggle mode and kill applications. 

Since you’re bound to have more applications than 16 (per page), you can swipe from left to right to go from page to page. I’m unsure on how much configuration I personally would add to the layout of the shade itself, but it’s a possibility. Once again, Launchpad is a way of accessing all your applications and launching them from wherever you are — whether from the SpringBoard or inside an application. 

Bottom Navigation Bar: 

When you first activate the shade (however you do that), it will always start at the Launchpad. A button shade tells you which button you are viewing. To change buttons, simply press or swipe along the bottom bar to move onto the next option. As mentioned above, you can tinker however you want. But, the other buttons are important as well. 

• Music — Instead of the music controls and what not being viewed from the start, simply swipe the bottom bar until Music is selected to view what that interface. My aim is to add more then just the standard music controls to this interface but I have not started on that yet. This would include the volume slider and what not as well. 
• Settings — I’m not even sure I want to keep this: this was just filler to be honest. However, this could be useful if you want quick access to certain settings. However, I may change it to something else later on. 

Note: This navigation bar could be potentially scrollable with more interfaces but I’m unsure of what to add. 

I’ll be sticking with this for a while so stay tuned for what is to come! You’re always welcome to give suggestions and critiques as well. Thanks!

© 2011 Joshua Tucker

Here’s my vision for a revised App Switcher for iOS. Instead of the bar at the bottom, the box will come up with all the running applications. It will be scrolling so that you can see all the applications you’re running and what not. The window will only be as big as the number of applications running (except to a certain limit — it will hit a size limit and than scroll from there). Just like normal, tapping the Home Button gets you out of it.

In order to quit applications, simply drag the icon until it quits (hence the “slide to quit” string). In order to get this functionality, you need to put the App Switcher into wiggle mode (hold one of the icons down until they move). This can also allow you to rearrange running applications if you wish to. Quitting multiple applications is easy as well. While in wiggle mode, tap the icons to check them. Then, from any of the checked applications, slide to quit. An alternative way of quitting multiple applications is to check them in wiggle mode and drag them outside the switcher and drop.

Note the page dots at the bottom: this window will have multiple pages so that you can house the other necessities like the iPod controls and what not. As always, concepts are concepts, however I feel that this is a strong contender.

You can also check out my recent concept on how to quit from applications (multiple - current native App Switcher).

Here’s two things to take away from this:

• Windows scroll vertically (up and down)
• Switching views (from App Switcher to iPod Controls for example), are down horizontally (left and right)

Stay tuned.

© 2011 Joshua Tucker

Here’s an alternative way of killing applications (even multiple). Instead of having the minus sign to kill the application, simply pick up the icon and drag it out of the switcher and drop. It kills it instantly. If you wish to kill more than one application, tap the applications you want to remove and drag and drop.

This concept was inspired in part by my multi-icon mover / multi-delete concept and Nevin Kapoor. 

P.S. You may find this concept similar to MultiCleaner, however this allows multiple applications to be dragged out and killed at the same time. 

© 2011 Joshua Tucker

Delete multiple applications on your SpringBoard at the same time. This concept goes hand-in-hand with my multi-icon mover concept. 

Here’s how it works:

• Go into wiggle mode and select the icons you wish to delete. You can note that a trash can icon appears on the status bar. 
• After selecting what you want, you can drag that stack to the status bar to delete them. As you get closer, the trash can moves over and adds the string “Delete” next to it.
• Dropping the stack on the status bar will bring up a confirmation window. If you choose “Yes, Continue,” or whatever, then it removes off the SpringBoard

In Case: If there are certain components of this concept that you don’t understand, visit my multi-icon mover concept to get some of the components clarified. 

Note: The icons I used would be technically not applicable for this concept because you can’t delete the stock icons. However, the concept applies to installable applications. 

© 2011 Joshua Tucker